Closed Bug 1279299 Opened 3 years ago Closed 3 years ago

Scrolling performance regressed


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

48 Branch



Tracking Status
firefox47 --- unaffected
firefox48 --- verified
firefox49 --- verified
firefox50 --- verified


(Reporter: heftig, Unassigned)




(Keywords: regression)


(4 files)

Attached file 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

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.
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)
Component: Untriaged → Graphics, Panning and Zooming
Keywords: regression
OS: Unspecified → Android
Product: Firefox → Firefox for Android
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.
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.
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.
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.
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).
Same problem here on a Xiaomi mi2s, firefox beta 48. No problems on 47.
(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.
Priority: -- → P1
See Also: → 1279433
Now that bug 1262807 has landed, can you try the latest nightly build from and see if it's any better?
Flags: needinfo?(jan.steffens)
Fixes the problem on my device. Thanks!
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.
Flags: needinfo?(jan.steffens)
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.
Depends on: 1280656
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.
The next beta (beta 4) should be much better as it will have the fix from bug 1262807.
Now that bug 1280656 is landed, are you still seeing the issue you described in comment 14?
Flags: needinfo?(jan.steffens)
Yeah, I do. There's still less checkerboarding after tab-switching. However, it tends to draw tile-height rows instead of individual tiles now.
That is, using the current Nightly. I'll try to make another video tonight.
Flags: needinfo?(jan.steffens)
Never mind on the tile-height rows; when it doesn't bug it's still mostly individual tiles.


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.
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.
I even checkerboards when I'm scrolling rather slowly.


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.
New build is at - 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).

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.
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.
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.
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.
Er, *is* a different problem. :)
(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.
Closed: 3 years ago
Resolution: --- → FIXED
Verified as fixed with Galaxy Note 5(6.0.1) on Release, Beta and Aurora(2016-08-09).
You need to log in before you can comment on or make changes to this bug.