I see the distinction as having more to do with input modality rather than performance per se.  On a touchscreen, 60fps-ish scrolling is mandatory so that the page tracks your finger.  With mousewheel or scrollbar dragging, low framerate is tolerable.  That's why desktop browsers scrolled at 5-10fps for decades without anybody complaining too much.

To be clear, I am strongly opposed to ever forcing main-scroll on any Android device.  The performance regression is completely unacceptable for us.  On the other hand I think you'll have a hard time disabling LCD text policy on any lo-dpi desktop without a flood of complaints about blurry text (although that side of it is just my two cents, you can try if you really want to).

Rather than spend effort trying out different tradeoff policies (both blurry text and scroll jank are undesirable), I'd recommend working to improve our architecture so that we can support impl-scroll with LCD-text and eventually get the best of both worlds.

Do you consider arc++ clank on cros an android devive? Discrepancy there is really weird.

I thought Clank wasn't made available to users on ARC++?  As for Android WebView on ARC++, OK, but not much consistency would be achieved by just supporting LCD text on that -- you'd also need to change the rest of the Android View system to support LCD text, which is probably a tall order.

This does sound like a good reason to disable LCD text in non-Android-world on ARC++ supporting devices, though.

(I still haven't seen ARC++ in action and actually recently ordered an 11-inch Chromebook so I can get a better idea.)

FWIW, I've changed ChromeOS to prefer compositing to LCD text in https://chromium.googlesource.com/chromium/src/+/e6e68ae222d21bdb5e872cf132925bc5440ccdcb for overlay scrollbars.

My guess is that greyscale AA has improved over the years where the difference from LCD text is not as marked as it used to be. I'm going to do some comparisons, perhaps it may be worth flipping the flag on all desktop platforms.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re comment #7, the distinction is now even blurrier (pun intended), as ChromeOS devices largely use the same input modalities as non-ChromeOS devices.

bokan, do you think we should do these experiments?

I think there's some risk here in that the effect may be better/worse on different monitors. On a broad platform like Windows we may have a large blind spot in this sense. There's also risk in web compat - I've seen lots of differences, particularly on Mac, where making changing the compositing behavior can affect things on the page (typically Mac's overlay scrollbars). So I don't think this would be a trivial change.

Given that we're putting lots of effort into getting slimming paint shipped, and that should fix these issues comprehensively, I think we should focus our efforts there.

Unless someone wants to take ownership and really push this, I suggest we close this for now.