Very slow scrolling the leaderboard of www.europeantour.com

UNCONFIRMED
Unassigned

Status

()

Core
Layout
UNCONFIRMED
2 years ago
2 years ago

People

(Reporter: vincent_dhaene, Unassigned, NeedInfo)

Tracking

50 Branch
x86_64
Windows 10
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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

2 years ago
Component: Untriaged → Event Handling
Product: Firefox → Core

Comment 1

2 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

2 years ago
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

Comment 2

2 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

2 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

2 years ago
Created attachment 8801822 [details] [diff] [review]
Tests the effect of a full Layout flush vs. not

Comment 5

2 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

2 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.
You need to log in before you can comment on or make changes to this bug.