Closed Bug 1252822 Opened 5 years ago Closed 5 years ago

Scrolling www.theguardian.com is really janky with APZ

Categories

(Core :: Panning and Zooming, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s - ---
firefox44 --- wontfix
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- wontfix

People

(Reporter: gkrizsanits, Assigned: BenWa)

References

Details

(Whiteboard: [gfx-noted])

tracking-e10s: --- → ?
Cc:ing Milan so we can get some gfx eyeballs on this one as well.
Correlated with xrender?  Or just e10s?
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(lsalzman)
Whiteboard: [gfx-noted]
A couple things:

1. The specified test in the summary comparison tps, the tab switching test: https://wiki.mozilla.org/Buildbot/Talos/Tests#tps 
(note that tp5o_scroll, the scrolling test, is also showing regressions: https://treeherder.allizom.org/perf.html#/e10s_comparesubtest?baseSignature=7c5b9d22cd3e43c0c764ac27eb9be826f85a689c&e10sSignature=64448bcd2e30dd836b0e47f9a44e8604ddf0be87). We're tracking that in bug 1186585.
2. We're using an old copy of the guardian.co.uk in the tp5 pageset. If you want the source data, you can grab it from here: http://talos-bundles.pvt.build.mozilla.org/zips/tp5n.zip
(In reply to Milan Sreckovic [:milan] from comment #2)
> Correlated with xrender?  Or just e10s?

I see DrawTargetCG in the profile, and the perfherder changes link shows windows, so xrender or lack of it is definitely not at fault here.
Flags: needinfo?(lsalzman)
So looking as a graph of OSX 10.10 and Win8 tp5o_scroll results over the past months, this is all I see:

https://treeherder.allizom.org/perf.html#/graphs?timerange=2592000&series=[mozilla-inbound,dbaade2dc703221d3287f7b3611302b4d34e8e7f,1]&series=[mozilla-inbound,ef368eea7a86c71180f5a6fc4af4672a595585d3,1]&series=[mozilla-inbound,0c8a722afb50907756257ad9df5781d6b03f9eb0,1]&series=[mozilla-inbound,f1095a72f5df055d3f330b688f71d370d5b26990,1]&selected=[mozilla-inbound,0c8a722afb50907756257ad9df5781d6b03f9eb0,18964,19029805]

The results are pretty much flat for the entire with no regressions expect for the selected alert there which seems to be concerning bug 1247049.

So I am just overall a bit confused by the bug report.

Is the bug report against OSX 10.10? Windows 8? All of the above? Is it concerning a regression? Or just that there is jank in the profile, or that we somehow shouldn't be trading shmems in e10s?
Just to be clear, this bug is about janky scrolling on theguardian.com on OS X, right? We're not trying to fix the tps regressions in this bug.

The profile was taken on OS X and shows some very large LayerTransaction blocks, which are blocking the compositor and causing the jank. There's one that ~1s long. Breaking that down in the view at [1] shows we're spending like 26% of time just drawing background colors which is a little absurd.

[1] https://cleopatra.io/#report=5fa58b550b1257cecaaa48a82ee90c50dbf5adca&jankOnly=true&filter=[{%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A445635471,%22end%22%3A445636503}]&selection=0,4019,4020,4021,4022,3678,4023,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,557,558,561,562,563,896,4033,4034,4035,4036,216,217,218,219,220,221,178,179,222,224,236,237,238,239,240,241,242,243,4352,4353,4354,245,246,402,247,2999,920,921,922,923,4465,924,189
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #6)
> Just to be clear, this bug is about janky scrolling on theguardian.com on OS
> X, right? We're not trying to fix the tps regressions in this bug.

Yes. I did manually scroll on www.theguardian.com with the latest nightly release on OSX 10.10.5 64bit.
(In reply to Lee Salzman [:lsalzman] from comment #5)
> So I am just overall a bit confused by the bug report.

This bug is about the scrolling issue on the actual site, which might or might not be related to the regression we see between e10s and non-e10s tps. Maybe the word "regression" in this context is a bit misleading indeed.
Does disabling APZ make a difference? Is this an issue with APZ or e10s?
Blocks: 1251388
(In reply to Chris Peterson [:cpeterson] from comment #9)
> Does disabling APZ make a difference? Is this an issue with APZ or e10s?

Oh, thanks, I should have tested this indeed. Yes, it seems to be completely APZ related. With APZ turned off the jank is gone: https://cleopatra.io/#report=947377688e8748873c9c08f6543ca1fc8e9072c7
Blocks: apz-desktop
Assignee: nobody → bgirard
Component: Graphics: Layers → Panning and Zooming
Flags: needinfo?(nical.bugzilla)
Summary: Scrolling www.theguardian.com is really janky with e10s → Scrolling www.theguardian.com is really janky with APZ
So I think to effectively work on this bug we need to have some sort of measurement of the jank on the page. In my experience the profiler is kind of hit or miss so I hacked up the the scroll-test bookmarklet from bug 894128 to do an APZ scroll and spit out the same frame interval data. I'm not 100% sure this will provide useful results but it's worth a shot.

Gabor, can you go to http://people.mozilla.org/~kgupta/scrolltest.html, bookmark the "scroll-test" link, then go to theguardian.com, click on the bookmark, and report the results it gives you? I want to make sure the frame intervals it records captures the jank you're seeing. Thanks!
Flags: needinfo?(gkrizsanits)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11)
> So I think to effectively work on this bug we need to have some sort of
> measurement of the jank on the page.

The jank was easily noticeable without any profiler. I think one of your recent APZ optimization fixed this issue, with the latest nightly the problem is gone, the page is smooth again.

> Gabor, can you go to http://people.mozilla.org/~kgupta/scrolltest.html,
> bookmark the "scroll-test" link, then go to theguardian.com, click on the
> bookmark, and report the results it gives you? I want to make sure the frame
> intervals it records captures the jank you're seeing. Thanks!

I see no janks any more, but here are the numbers anyway:
Page: http://www.theguardian.com/international
Steps: 26
Duration: 666 ms

Window size: 1271 x 690
Average interval: 25.02 ms
STDDEV intervals: 12.35 ms

intervals histogram:
4.0 - 6.0 ms: 1
14.0 - 15.9 ms: 2
15.9 - 17.3 ms: 7
17.3 - 18.0 ms: 2
18.0 - 22.0 ms: 5
22.0 - 32.0 ms: 1
35.0 - 50.0 ms: 7
50.0 - 80.0 ms: 1

intervals:
16.84
20.52
35.14
48.31
45.24
40.20
35.43
37.41
24.67
20.85
19.81
20.95
51.28
15.88
17.80
15.58
16.76
16.44
17.05
16.82
16.27
42.76
17.77
5.75
18.55
16.32
Flags: needinfo?(gkrizsanits)
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #12)
> The jank was easily noticeable without any profiler. I think one of your
> recent APZ optimization fixed this issue, with the latest nightly the
> problem is gone, the page is smooth again.

Great to hear! I don't think any of my patches would have fixed this, but one of Markus/Matt's may have. Or it could just be that the page changed. Getting a fix window would be nice if you have time but since we'll probably uplift all those things regardless it's probably not that important.

> I see no janks any more, but here are the numbers anyway:

Thanks! Some of the intervals are longer than I'd like but 51.28ms is the highest which is much better than the ~1s that showed up in the profile earlier. I'm going to close this bug as WFM since it seems to be fixed.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
This may have been fixed by bug 1251527.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #13)
> (In reply to Gabor Krizsanits [:krizsa :gabor] from comment #12)
> > The jank was easily noticeable without any profiler. I think one of your
> > recent APZ optimization fixed this issue, with the latest nightly the
> > problem is gone, the page is smooth again.
> 
> Great to hear! I don't think any of my patches would have fixed this, but
> one of Markus/Matt's may have. Or it could just be that the page changed.
> Getting a fix window would be nice if you have time but since we'll probably
> uplift all those things regardless it's probably not that important.

The talos tp5o_scroll test (which used a static copy of the site) showed a dramatic improvement:

https://treeherder.mozilla.org/perf.html#/graphs?series=[mozilla-inbound,eae2c39e3a3009a2c91dae80cc32245b8c2c8318,1]

Looking at the pushlog, it looks like it was some patches in bug 1253860 which are responsible:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=412c5cae8dea&tochange=b0e1cefc94ce
(In reply to William Lachance (:wlach) from comment #15)
> Looking at the pushlog, it looks like it was some patches in bug 1253860
> which are responsible:

Those patches wouldn't have affected wheel/trackpad scrolling.
You need to log in before you can comment on or make changes to this bug.