Closed
Bug 1235839
Opened 9 years ago
Closed 9 years ago
Slow scrolling on http://deeplearning.net/reading-list/
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox46 | --- | affected |
People
(Reporter: marco, Unassigned)
References
Details
(Keywords: perf, Whiteboard: gfx-noted)
Attachments
(1 file)
(deleted),
application/x-7z-compressed
|
Details |
The animation in "tag cloud" on the right causes scrolling to be really slow.
Reporter | ||
Comment 1•9 years ago
|
||
Updated•9 years ago
|
Comment 2•9 years ago
|
||
This profile seems to be in a .bin format? What kind of profiler were you using with the attached profile? Thanks!
Flags: needinfo?(mchang) → needinfo?(mcastelluccio)
Comment 4•9 years ago
|
||
From the profiles, I see super long 500+ms times to do XRender::Sync, _XSEND and XUnlockDisplay. I know we're planning to reduce our dependence on XRender, which should help this test case.
Depends on: 1241832
Reporter | ||
Comment 5•9 years ago
|
||
It's still slow, I can grab another profile (although bug 1241832 caused bug 1247935, so I don't know if it'll stick).
Reporter | ||
Comment 6•9 years ago
|
||
This is now fixed (both with gfx.xrender.enabled set to true or false), I wonder if this was fixed by the same fix for bug 1247935.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Comment 7•9 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #6)
> This is now fixed (both with gfx.xrender.enabled set to true or false), I
> wonder if this was fixed by the same fix for bug 1247935.
That makes sense, yes. As Mason noted, a lot of the profile was spent in XSync waiting for stuff to be drawn. So if there was somehow contention for the connection to the X display, the changes I made in bug 1247935 would massively reduce that contention, since it no longer uses the XSync mechanism at all.
You need to log in
before you can comment on or make changes to this bug.
Description
•