1279299 - Scrolling performance regressed

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: Toolbar, defect, P1)

Description

[Jan Alexander Steffens [:heftig]]

Attachment: about:support.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160607195100
Firefox for Android

Steps to reproduce:

Scroll on https://lwn.net/Articles/688462/

Noticed first in Aurora 48; when Beta got updated to 48, it was affected as well.


Actual results:

Scrolling is jerky (low FPS), redraws more slowly. Shows low-res and white tiles more often. Gets worse with faster scrolling.



Expected results:

47 was much smoother.

Comment 1

[Jan Alexander Steffens [:heftig]]

User Agent: Mozilla/5.0 (Android 6.0.1; Mobile; rv:48.0) Gecko/48.0 Firefox/48.0
Build ID: 20160607191837
Multiprocess Windows: 0/1 (Disabled)

Model: Nexus 6P
Product: angler
Manufacturer: Huawei
Hardware: angler
OpenGL: Qualcomm -- Adreno (TM) 430 -- OpenGL ES 3.1 V@127.0 (GIT@I8366cd0437)

Comment 2

[Kartikaya Gupta (email:[e-mail])]

When I scroll the page on 47 and 48 it just scrolls a lot slower on 48. However I don't see jerky/janky scrolling. Are you able to make a video of what you're seeing? Ideally using adb shell screenrecord.

Comment 3

[Jan Alexander Steffens [:heftig]]

Attachment: Attempt to screenrecord 47

Comment 4

[Jan Alexander Steffens [:heftig]]

Attachment: Attempt to screenrecord 48

Comment 5

[tallus]

I'm seeing this as well, across most pages on 48 beta. It's bad enough I've had to stop using it.
the attachments to 1279300 show what my experience is like.

Comment 6

[go_noisemaker]

Attachment: Free scrolling in 48.0b1 vs. 46 (=47)

Scrolling behaviour definitely changed (for the worse) in 48.0b1. Trying to revert scrolling-related prefs in about:config to 46.0 values did nothing. Attached screencast shows scrolling in 48.0b1 then in 46.0 release (identical to all 47 betas and previous versions). Device is a Galaxy S4 with CM13.

Comment 7

[go_noisemaker]

In reply to myself: probably due to bug 1229462, although I still find scrolling to be less smooth than in pre-48 (see the first two attachments). On a side note, I'm also annoyed that the toolbar doesn't appear anymore when scrolling to the end of the page.

Comment 8

[Jan Alexander Steffens [:heftig]]

Right; I did notice that flinging is faster now, but I also noticed jerkier scrolling when not flinging at all (IIRC the videos I attached show this, with the 48 one having less frames overall despite being longer).

Comment 9

[royvandervegt]

Same problem here on a Xiaomi mi2s, firefox beta 48. No problems on 47.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

(In reply to go_noisemaker from comment #7)
> On a side note, I'm also annoyed that the toolbar doesn't appear anymore
> when scrolling to the end of the page.

This sounds like something that we should fix, can you please file another bug for it?

As for this bug, we've got a bunch of reports of this (see "See Also" bugs) and we'll need to investigate and figure out what's going on here. Marking P1.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Waiting for bug 1262807 to get resolved.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Now that bug 1262807 has landed, can you try the latest nightly build from nightly.mozilla.org and see if it's any better?

Comment 13

[royvandervegt]

Fixes the problem on my device. Thanks!

Comment 14

[Jan Alexander Steffens [:heftig]]

The bad invalidation from bug 1262807 is indeed gone, and the jank it caused went with it. However, it's still not as smooth as release.

I'm observing some very pathological painting on the same page when completely zoomed out, where Nightly decides to paint very large sections very slowly, causing very long checkerboarding. Bizarrely, the symptom is gone after tab-switching away and back, until the page is reloaded. I'll try to get a video.

Comment 15

[Jan Alexander Steffens [:heftig]]

Video: https://drive.google.com/open?id=0B5YJHo8iJQ94MFUzeEhuRjltUjg

Comment 16

[Kartikaya Gupta (email:[e-mail])]

Huh, that's pretty strange behaviour. On my Z3C I mostly get the expected behaviour (where paintflashing shows square tiles being painted). If I scroll at a medium-fast speed I sometimes get entire rows of tiles painted together, which I'm pretty sure is intentional as well (when we're about to checkerboard we turn off progressive tile-by-tile painting). I suspect that's what's happening for you, but just a lot more frequently. As Randall said in bug 1279433 comment 9, I think reducing the max velocity will probably help somewhat.

Comment 17

[benedikt.winder]

Same for me on Android Beta for Android 48 on a Nexus 5x and a Moto G 2015. The scrolling is really slow and stuttering. In the stable Firefox 47 all works fine. The Problem is on every site i tried.

Comment 18

[Kartikaya Gupta (email:[e-mail])]

The next beta (beta 4) should be much better as it will have the fix from bug 1262807.

Comment 19

[Kartikaya Gupta (email:[e-mail])]

Now that bug 1280656 is landed, are you still seeing the issue you described in comment 14?

Comment 20

[Jan Alexander Steffens [:heftig]]

Yeah, I do. There's still less checkerboarding after tab-switching. However, it tends to draw tile-height rows instead of individual tiles now.

Comment 21

[Jan Alexander Steffens [:heftig]]

That is, using the current Nightly. I'll try to make another video tonight.

Comment 22

[Jan Alexander Steffens [:heftig]]

Never mind on the tile-height rows; when it doesn't bug it's still mostly individual tiles.

Video: https://drive.google.com/open?id=0B5YJHo8iJQ94RHJ3TGlibmE1dkU

Fennec 50.0a1 20160703030210

In this video:
0:05 After initial zoom out, painting is slow.
0:20 After switching tabs, painting is fast.
0:31 After zooming in and out again, painting is slow.
0:50 After zooming in a bit, painting is fast.
1:01 After zooming out again, painting is slow.
1:17 After switching tabs again, painting is fast.

Comment 23

[Kartikaya Gupta (email:[e-mail])]

Ah, interesting. I tried and failed to reproduce this on both the Nexus 4 and Sony Z3C, in both portrait and landscape. I can make a build with more logging but I need to first come up with some sort of theory as to why this is happening - and I'm at a loss there. I was wondering if it's related to the zoom level or width but then switching tabs away and back shouldn't make a difference.

Comment 24

[Jan Alexander Steffens [:heftig]]

I even checkerboards when I'm scrolling rather slowly.

Video: https://drive.google.com/open?id=0B5YJHo8iJQ94dWZPN25fZnhhcnM

It seems to be linked to whether a scroll is going on - the checkerboard starting at 0:44 isn't getting painted until shortly after I release my finger at about 1:02.

Comment 25

[Kartikaya Gupta (email:[e-mail])]

New build is at https://treeherder.mozilla.org/#/jobs?repo=try&revision=61174007387e - as before, please get the video along with the log. Note that you can clear the log using "adb logcat -c", so run that before you start recording with "adb logcat -v time", and that way the log collected will be just the buggy behaviour. Also if you go to about:config and add a new boolean pref with the name "apz.check_resolution" and set the value to "false" it will skip that resolution check. If that resolves the problem it will be good to know (I'd like the log either way though).

Comment 26

[Jan Alexander Steffens [:heftig]]

Video: https://drive.google.com/open?id=0B5YJHo8iJQ94WTNyclBTMmZHeDA
Log: https://drive.google.com/open?id=0B5YJHo8iJQ94ZHFleGpEQkd6V00

Events:
08:58:28.140 (0:05) Full zoom out => bug
08:58:55.540 (0:32) Zoomed in slightly => bug
08:59:00.025 (0:37) Zoomed in more => no bug
08:59:03.110 (0:40) Full zoom out => bug
08:59:09.313 (0:46) Tab switch back => no bug
08:59:17.249 (0:54) Full zoom out => bug
08:59:39.529 (1:17) I switch off apz.check_resolution
08:59:41.444 (1:18) Tab switch back => no bug
08:59:45.782 (1:23) Full zoom out => bug
09:00:13.505 (1:50) Rare instance of regular tiling
09:00:20.423 (1:57) Rendering suddenly blanks until 09:00:20.903 (1:58)
09:00:30.033 (2:07) Rendering suddenly blanks until 09:00:34.327 (2:11)
09:00:39.643 (2:17) Tab switch back => no bug
09:00:48.130 (2:25) Full zoom out => bug
09:00:49.252 (2:26) Displayport is repeatedly redrawn while scrolling

As before, rendering is fine after a tab switch until the next full zoom-out. Without check_resolution, the displayport doesn't lock up anymore, but the rendering pattern is still different and speed is still poor.

Comment 27

[Kartikaya Gupta (email:[e-mail])]

I'm not sure where you got the timestamps from in comment 26 but the millisecond values you posted don't seem to line up with the timestamps in the bigpaint5.log file. Still, they're close enough.

So from the log it looks like the resolution check is indeed kicking in and causing the displayport to get stuck, and that's part of the problem you were seeing. After flipping the pref that doesn't happen any more, and the behaviour is visibly better.

The other problem that shows up in the log is that some values are coming out as NaN. The first instance in the log is at 09:00:20.327 where the velocity's x-component is NaN, and that then propagates to a bunch of places. It's hard to say if this causes the rendering blanking, but it lines up in the timestamps and is certainly not correct.

Other than that I see some slow paints, in that the time between the repaint request being sent and the corresponding NotifyLayersUdpate coming back is on the order of a few hundred milliseconds. When that happens and there's a high velocity at the same time, there's bound to be some checkerboarding, but I don't know if there's much we can do about that right now.

Let's get the first two issues fixed and then see what's left.

Comment 28

[Kartikaya Gupta (email:[e-mail])]

Both fixes should be in the July 07 nightly. Jan, can you let me know if this nightly behaves better? If there are still issues I'll rebase my logging patches and see if we can figure out the remaining issues.

Comment 29

[Jan Alexander Steffens [:heftig]]

Much improved. There's still *something* different where it likes to draw entire rows (after zooming out) instead of tiles (after switching tabs), but it seems to perform the same.

What I did notice though, is running into overscroll at seemingly random times, interrupting the scroll. But that's not a different problem.

Comment 30

[Jan Alexander Steffens [:heftig]]

Er, *is* a different problem. :)

Comment 31

[Kartikaya Gupta (email:[e-mail])]

(In reply to Jan Steffens from comment #29)
> Much improved. There's still *something* different where it likes to draw
> entire rows (after zooming out) instead of tiles (after switching tabs), but
> it seems to perform the same.

Great, thanks! I'll mark this bug closed then. I'm not entirely sure why it's drawing rows instead of tiles but as long as the performance is the same it shouldn't really matter.

> What I did notice though, is running into overscroll at seemingly random
> times, interrupting the scroll. But that's not a different problem.

Yeah I've noticed this too. I just filed bug 1285239 for it.

Comment 32

[Alex Caziuc]

Verified as fixed with Galaxy Note 5(6.0.1) on Release, Beta and Aurora(2016-08-09).