Closed
Bug 1256133
Opened 9 years ago
Closed 3 years ago
Slow, janky scrolling on this support.mozilla.org thread with e10s enabled
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
People
(Reporter: asqueella, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf, Whiteboard: gfx-noted)
On a new profile, current nightly:
1. Open https://support.mozilla.org/en-US/questions/1111080
2. Scroll to the bottom of the page with Cmd+Down or with the three(?)-finger swipe.
3. Scroll to the top
4. Repeat
With e10s scrolling is much slower.
When taking the profiles below I did this: scroll down, scroll up, wait a second; repeat.
e10s: https://cleopatra.io/#report=fd056b554af26623e0d24467e351a89d799664e5&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A214795,%22end%22%3A217711%7D,%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A216117,%22end%22%3A216767%7D%5D&selection=0,2662,2663,2664,2665,2359,2666,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,1039,1040,1041,1042,1043,1044,2713,2714,2715,2716,168,169,170,171,183,184,185,186,187,188,189,190,214,215,216,217,218,219,2877,2878,2879,196,197,198,199,2889
no e10s: https://cleopatra.io/#report=f0ac7ed640459a01ac92b87533ab7f23eb1ae32d&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A15676,%22end%22%3A17733%7D%5D&selection=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,502,503,504,505,506,507,508,509,510,511,1758,343,344,447,448,449,450,451,453,463,464,465,466,467,468,468,469,470,738,739,740,472,473,474,475
This is likely a duplicate, but I couldn't find a list of known root causes of bad scrolling perf, and a way to confirm that my problem matches a known cause, so I'm filing this anyway.
Comment 1•9 years ago
|
||
What do you mean by slow scrolling? Is it jumpy or is there missing content?
I expect this might have to do with the horizontal scrolling. Do you see this problem on other support questions that are not horizontally scrollable?
Reporter | ||
Comment 3•9 years ago
|
||
The scrolling is jumpy: you can notice the time it takes to paint the next frame, both visually and in the profile.
This is a retina screen, yes.
> I expect this might have to do with the horizontal scrolling.
That was a good guess! I removed the wide <p> from the first post (using the Devtools Inspector) and scrolling became as fast as without e10s.
Flags: needinfo?(asqueella)
Updated•9 years ago
|
Component: Graphics → Panning and Zooming
Comment 4•9 years ago
|
||
Bug 1251638 is another bug where we've seen the presence of a horizontally scrollable element have a negative effect on scrolling performance. It's possible these share a root cause.
See Also: → 1251638
Updated•9 years ago
|
Whiteboard: gfx-noted
Updated•9 years ago
|
Flags: needinfo?(jmathies)
Updated•9 years ago
|
Flags: needinfo?(jmathies)
Comment 6•9 years ago
|
||
Yeah this is next on my to-do list.
Comment 7•9 years ago
|
||
I've been using bug 1243081 to investigate since I'm assuming they're the same underlying issue, and it's easier for me to reproduce on that URL. From the APZ side I don't think there's much we can do here without making checkerboarding worse. Doing something like implementing bug 1261166 might help.
Depends on: 1261166
Comment 8•9 years ago
|
||
As with bug 1243081, applying the WIP patch on bug 1261166 makes the transaction times here drop to ~0. I specifically tested scrolling up and down on the provided URL using fn+left/right arrow (equivalent to "home"/"end" scrolling on mac) and compared the transaction times with and without bug 1261166.
Comment 9•9 years ago
|
||
(In reply to (Back on May31) Kartikaya Gupta (email:kats@mozilla.com) from comment #8)
> As with bug 1243081, applying the WIP patch on bug 1261166 makes the
> transaction times here drop to ~0.
Just to make sure I'm understanding this correctly: the slowness here is specific to Mac?
Comment 10•9 years ago
|
||
I believe so.
Updated•9 years ago
|
Updated•9 years ago
|
Comment 11•8 years ago
|
||
Unassigning since I'm not doing anything here, it is just waiting on the ClientStorage implementation.
Assignee: bugmail → nobody
status-firefox51:
--- → affected
Updated•8 years ago
|
Priority: P1 → P2
Comment 12•8 years ago
|
||
Sounds like the ClientStorage work is still stalled, so this won't get fixed for 49 or 50 most likely.
Updated•8 years ago
|
status-firefox52:
--- → wontfix
status-firefox53:
--- → affected
Comment 13•6 years ago
|
||
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Updated•3 years ago
|
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•