1475035 - (android-scrolling) [meta] Make Android scrolling responsive and predictable

Status: NEW

(GeckoView :: General, defect, P3)

Comment 1

[Mark]

You could add bug 1457702. But IIUC Fenix means one day we'll have a new toolbar so it might not be worth worrying about.

Comment 2

[Chris Peterson [:cpeterson]]

(In reply to Mark from comment #1)
> You could add bug 1457702. But IIUC Fenix means one day we'll have a new
> toolbar so it might not be worth worrying about.

Thanks! Better to track the bug here and confirm it gets fixed than to lose it.

Comment 3

[Mark]

Add bug 1432019? Kats can't reproduce it but seems to believe me ;)

Comment 4

[Chris Peterson [:cpeterson]]

(In reply to Mark from comment #3)
> Add bug 1432019? Kats can't reproduce it but seems to believe me ;)

Thanks! Definitely worth testing.

Comment 5

[Mark]

I just filed bug 1483605, you could add it to the list. 


You can call me the Jankmeister :)

Comment 6

[Chris Peterson [:cpeterson]]

Thanks! We'll review and prioritize bug 1483605 tomorrow.

Comment 7

[Mark]

I thought I'd share on this thread some of the tests I've been doing as part of bug 1432019 and bug 1484173.

The tl;dr version is I think scrolling on Nightly is already as good as, arguably superior, to Chrome Beta on low end hardware. In particular flings on Nightly are now better than Chrome, and I think once bug 1484173 is fixed Nightly drag scrolls will be better than Chrome Beta as well. There also seem to be some fling flywheel issues on Chrome Beta which don't happen on Nightly. 

So good news!

On mid-range hardware all these the differences become hard to spot, I think there's enough performance for both browsers.

 

I've mostly focused on my older low end phones (Snapdragon 420 and 425, ~1.4 GHz ARM53, so fairly representative of an entry level phone today).

I compared current Nightly, which 
- has the fix for over-compositing (bug 1484173) thus improving flings, but 
- does not have the fix for the vsync vs touchevent race condition (bug 1432019) which when fixed will improve drag scrolls (I can more-or-less simulate the fix by moving Nightly to sofware vsync at 60 fps)

I compared with with Chrome Beta, on mozilla.org and bbc.co.uk/news. Neither site has adverts so it took some of the variables out of the way. Both sites have (JavaScript?) images which fade in but otherwise are fairly boring.

On both sites Chrome is pretty choppy, Nightly is IMHO superior.

Flings:- In particular when images fade in Chrome Beta sometimes freezes the fling for a reasonable fraction of a second. Sometimes this also happens without images popping in, just flinging. There are also a bunch of smaller but still irritating janks. I would say when I fling from top to bottom and back a couple of times I see one or two major freezes and 10-20 smaller janks.  Also if I do a huge top-to-bottom fling I occasionally see blank screen with checkerboarding. Nightly on the other hand now has flings which are pretty smooth. Occasionally there is a small jank when an image pops in, but not often. But there is never the major freeze and the jank is only a few millimeters. I almost never see checkerboarding, but on the other hand I sometimes see the "low precision buffer" pixellated version of the page briefly before the real content paints.

Drag scrolls:- Chrome Beta has choppy drag scrolling much the same as today's Nightly (which still has the vsync vs touchevent race issue). If I more-or-less simulate the fix for this issue by moving to software vsync Nightly's drag scrolling is superior to Chrome Beta's. (I hope the actual real fix will be superior to my more-or-less fix).

Flywheel:- On Chrome Beta the flywheel during a fling seems a bit funny, sometimes the final fling velocity doesn't change how I'd expect. Hard to describe. Nightly seems more consistent.

So all good news. Remember this is on low end hardware.

I noodled with OMTP but didn't see any material changes (I think you'd have to do some proper engineering not just eyeballing). I also noodled with the displayport size and the low precision buffer resolution. Mostly I made things worse, but I think there is room for improvement here. In particular the new Chromesque fling phyics mean it's easy to do really fast flings which can often fall outside the displayport. But again it's not something that's going to be fixed just by eyeballing. So my conclusion is:- if it ain't broke...

I hope you guys can persevere with the remaining fixes eg bug 1484173, bug 1499941. When all the dust has settled from those I'd like to do some more tests and see what can still be improved. But Nightly has come a long way in the last couple of months.

Comment 8

[Chris Peterson [:cpeterson]]

Changing the bug summary to "make scrolling responsive and predictable" to highlight the specific complaints identified by our recent user research on perceived performance.

Comment 9

[Mark]

This effectively got a wontfix from the Focus guys, I guess because a fix would be too much work. But it definitely falls under the category "unpredictable" :) It still bugs me when I'm scrolling.

https://github.com/mozilla-mobile/focus-android/issues/2789

Just FYI.

Comment 10

[Karl Dubost💡 :karlcow]

There is a regression because of scroll anchoring. Do we have a bug for these?
https://webcompat.com/issues/28021

Comment 11

[Chris Peterson [:cpeterson]]

(In reply to Karl Dubost💡 :karlcow from comment #10)

There is a regression because of scroll anchoring. Do we have a bug for these?
https://webcompat.com/issues/28021

Bug 1519644 is the meta bug for scroll anchoring.

Comment 12

[Chris Peterson [:cpeterson]]

I'm editing a bunch of GeckoView bugs. If you'd like to filter all this bugmail, search and destroy emails containing this UUID:

e88a5094-0fc0-4b7c-b7c5-aef00a11dbc9