1483605 - GeckoView:- single frame of jank as first screenful is flinged

Status: RESOLVED FIXED

(GeckoView :: General, defect, P2)

Description

[Mark]

Attachment: A fling jank fennec aug 2018 - 2.pdf

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180811103606

Steps to reproduce:

In Fennec or or Focus + Geckoview.

Start at the top of a page and fling gently upwards. As the bottom of the first screenful inertia scrolls off the top of the screen, there is always a single frame of scroll jank. One frame is "short" i.e. the content does not move as far as all the other frames. This leads to perceptible jank. I think the problem always happens at exactly the same point on the page.

It's hard to see. I took a screen video capture, copied it to my Mac and watched it frame-by-frame in Quicktime. It's easy to see the "short" frame.

If I make the displayport bigger by setting apz.y_skate_size_multiplier and apz.y_stationary_size_multiplier to larger values the single janky frame moves further down the page.

I see this on all pages I have checked. I see it on Fennec Nightly and on Focus + Geckoview. On Focus + GeckoView it happens  about an inch further down the page.   I see it on a few different phones. 

I think the problem is related to viewport / displayport calculations, I wonder if the different position at which it happens is because Focus has a slightly different displayport or viewport size?

I don't think this is related to bug 1432019 (I could be wrong) because I can fix bug 1432019 by setting layout.frame_rate to 60 whereas layout.frame_rate has no effect on this current bug.  BUT it might have some relationship to bug 1432019 because they both seem to depend on the size of the displayport.

I don't think this is related to the new Chrome-esque fling physics because I see the same problem if I set apz.android.chrome_fling_physics.enabled to FALSE.

I think this bug is more like bug 1401526, a mis-calculation of the viewport position (????)

The first attachment A is a series of consecutive frames grabbed from a video of mozilla.org being flung on Fennec. The left hand image is the page scrolled to the top. At the very bottom of the screen is the start of the red picture of the guy in the yellow shirt. I call this point X. The right hand series is a set of consecutive frames grabbed out of the fling video. As the red picture point X inertia scrolls to the top of the screen there is a single frame which does not move as far as all the others, as you can see from the series of red horizontal lines.

I will also attach (B through D) video grabs of Fennec and Focus + GeckoView doing the same thing on two different pages. If you load them into e.g. Quicktime and scrub frame by frame you can see the short frame. Each uploaded file has a number e.g. 01-25 which is seconds into the video at which the short frame happens (1.25 seconds into the video).

(You can scrub easily in Quicktime by moving into full screen mode and using Edit > Trim to bring up a great big scrub bar). 

Enjoy

Comment 1

[Mark]

Attachment: B fling jank fennec mozilla 01-43.mp4

Comment 2

[Mark]

Attachment: C fling jank focus mozilla 01-44.mp4

Comment 3

[Mark]

Attachment: D fling jank fennec ars 01-32.mp4

Comment 4

[Mark]

Attachment: E fling jank focus ars 01-25.mp4

Comment 5

[Mark]

NB both attachment C and E are Focus + GeckoView (the Nightly channel). B and D are Fennec Nightly, but it happens on any version of Fennec I've tried.

Comment 6

[Mark]

see bug 1432019 comment 34 and comment 35 and its attachment. I think it's maybe related.

Comment 7

[Mark]

I think I see the same single frame jank when flinging up from the bottom of the document. I haven't done the frame by frame but I think my finely honed eyeball can see it. So this bug seems symmetrical at the two ends of the document much like bug 1432019. I think it's all somehow connected to the displayport hitting/leaving its end stops and how the viewport moves within the displayport.

Comment 8

[Chris Lord [:cwiiis]]

(In reply to Mark from comment #7)
> I think I see the same single frame jank when flinging up from the bottom of
> the document. I haven't done the frame by frame but I think my finely honed
> eyeball can see it. So this bug seems symmetrical at the two ends of the
> document much like bug 1432019. I think it's all somehow connected to the
> displayport hitting/leaving its end stops and how the viewport moves within
> the displayport.

Have you tried this with paint-flashing turned on? (I can't remember the about:config key for it, but search for 'flash' and it'll probably come up)

I'm wondering if it's bug 1126044. This should have been fixed by bug 1012752, but maybe there's some subtle bug in that code, or some bad interaction or edge-case wrt zooming or some such. If the whole page flashes during that jank, it's likely something like this.

Comment 9

[Mark]

I set nglayout.debug.paint_flashing TRUE.

The screen showed squares (tiles?) in hideous pastel shades like a bad pair of golf trousers

But I didn't see a whole screen flash during the jank

I tried mozilla.org and arstechnica.com, both of which show the jank. Neither showed a whole screen flash.

Comment 10

[Chris Lord [:cwiiis]]

(In reply to Mark from comment #9)
> I set nglayout.debug.paint_flashing TRUE.
> 
> The screen showed squares (tiles?) in hideous pastel shades like a bad pair
> of golf trousers
> 
> But I didn't see a whole screen flash during the jank
> 
> I tried mozilla.org and arstechnica.com, both of which show the jank.
> Neither showed a whole screen flash.

With paint flashing on, any particular invalidation is shaded a different colour - during that initial jank at the top/bottom of the screen, do a significant number of tiles change colour? If not, you can ignore my suggestion, that (probably) isn't it.

Two other prefs I'd personally be interested in to rule out jank from painting would be apz.(x/y)_skate_size_multiplier - iirc, the displayport shrinks slightly at speed to reduce the chance of checkerboarding - if you change that to the same number as apz.(x/y)_stationary_size_multiplier, does that change anything?

Tbh, you can probably ignore most of my suggestions, it's been years since I worked on any of this code, but I'm still interested :)

Comment 11

[Mark]

> With paint flashing on, any particular invalidation is shaded a different
> colour - during that initial jank at the top/bottom of the screen, do a
> significant number of tiles change colour? If not, you can ignore my
> suggestion, that (probably) isn't it.
Not really, nothing very exciting happens

> Two other prefs I'd personally be interested in to rule out jank from
> painting would be apz.(x/y)_skate_size_multiplier - iirc, the displayport
> shrinks slightly at speed to reduce the chance of checkerboarding - if you
> change that to the same number as apz.(x/y)_stationary_size_multiplier, does
> that change anything?
They have the same value in Fennec, increasing y_stationary makes the jank happen further down the screen, as in Comment 0.

I think this might be the same as bug 1432019 and Kats is doing some test builds on that, let's see what he comes up with...

Comment 12

[Chris Peterson [:cpeterson]]

P2 because this bug doesn't need to block Focus 8.0 or FxR 1.1.

Comment 13

[Mark]

This is fixed in 65, it was part of bug 1484173.

Comment 14

[Chris Peterson [:cpeterson]]

(In reply to Mark from comment #13)

This is fixed in 65, it was part of bug 1484173.

Cool! Thanks for confirming the fix. I'll close this bug.