Closed
Bug 1308701
Opened 8 years ago
Closed 3 years ago
Very slow scrolling the leaderboard of www.europeantour.com
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: vincent_dhaene, Unassigned)
References
()
Details
Attachments
(1 file)
937 bytes,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161006105459 Steps to reproduce: - Open the leaderboard of http://www.europeantour.com, e.g. http://www.europeantour.com/europeantour/season=2016/tournamentid=2016078/leaderboard/index.html#/leaderboard - Scroll using mousewheel or scrollbars Actual results: Scrolling is very slow and response time bad
Updated•8 years ago
|
Comment 1•8 years ago
|
||
Indeed, it is bad on non-e10s, and with e10s there is lots of checkerboarding (but scrolling is very smooth). The page is obviously doing something silly by causing lots of re-creation of layout objects. Scrolling is horrible also on other browsers: Chrome on linux is checkerboarding a lot, and scrolling Chrome on Windows is somehow odd, slow but no checkerboarding. Edge is doing quite well. Jet, could someone from layout team perhaps profile this a bit. It is a bug in the web site, sure, but maybe there are also things to improve in Gecko.
Component: Event Handling → Layout
Flags: needinfo?(bugs)
Reporter | ||
Updated•8 years ago
|
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Comment 2•8 years ago
|
||
I boiled these down to two test cases to isolate the problem: http://media.junglecode.net/test/1308701/test_slow.html#/leaderboard http://media.junglecode.net/test/1308701/test_fast.html#/leaderboard The only difference between these two cases is a single line commented in a JS file: http://media.junglecode.net/test/1308701/asset_files/leaderboardBundle_slow.js http://media.junglecode.net/test/1308701/asset_files/leaderboardBundle_fast.js Look for "// xxx jet: comment this line out to speed this up!" to find the relevant line. The root cause is that the following call is slower in Gecko than in other browsers: $(ele).offset().top Smells like a dupe, but I haven't found one yet. Cam: have you seen this one before?
Flags: needinfo?(bugs) → needinfo?(cam)
Comment 3•8 years ago
|
||
BTW, jquery $Element.offset() depends on Element::GetBoundingClientRect() which does a full Layout flush in Gecko. Blink/Webkit doesn't appear to do a Layout/Style flush for that call: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Element.cpp?q=GetBoundingClientRect&sq=package:chromium&l=1131 Speeding up GetBoundingClientRect() would be great, but I'm not sure what we'll break by suppressing the reflow in this call.
Comment 4•8 years ago
|
||
Comment 5•8 years ago
|
||
(In reply to Jet Villegas (:jet) from comment #3) > Speeding up GetBoundingClientRect() would be great, but I'm not sure what > we'll break by suppressing the reflow in this call. It turns out we may break a fair bit. The ASSERTs in the patch in comment 4 is firing quite a bit.
(In reply to Jet Villegas (:jet) from comment #3) > which does a full Layout flush in Gecko. Blink/Webkit doesn't appear to do a > Layout/Style flush for that call: > > https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/ > Element.cpp?q=GetBoundingClientRect&sq=package:chromium&l=1131 Yes it does. One of the first things in that function is a call to clientQuads, whose first line is: document().updateStyleAndLayoutIgnorePendingStylesheetsForNode(this); which sure sounds like the same thing. > Speeding up GetBoundingClientRect() would be great, but I'm not sure what > we'll break by suppressing the reflow in this call. I think the key question here is why the work that the flush triggers is slower.
Comment 7•8 years ago
|
||
(In reply to David Baron :dbaron: ⌚️UTC-7 from comment #6) > I think the key question here is why the work that the flush triggers is > slower. I took another look here and jquery's outerHeight() is even slower after the GetBoundingClientRect() flush happens. I updated my comments in the affected JS file: http://media.junglecode.net/test/1308701/asset_files/leaderboardBundle_slow.js This appears to be a known issue in the version of jquery used on this site: https://bugs.jquery.com/ticket/12689 The site would do well to cache the results of outerHeight() outside of the scrolling loop, but we may still be able to speed that up in Gecko.
Comment 8•3 years ago
|
||
Page performance looks good for me these days.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(cam)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•