New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 629660 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

scrolling ebay on mac unacceptably janky while loading

Project Member Reported by primiano@chromium.org, Jul 19 2016

Issue description

Canary (54.0.2800.0) on a MacBook Pro retina (El Capitan)

Page: http://www.ebay.co.uk/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR0.TRC0.H0.Xd-line+wire.TRS0&_nkw=d-line+wire&_sacat=0

Attaching trace.

The dynamic is as follows: while the page is being loaded scrolling is terrible. At some points my perception is that I reach ~5 fps.
I took a quick look at the trace. Looks like in the middle of a scrolling the main thread is busy with there tasks like (at T=4100 in the trace):
50 ms of v8 compilation + 30ms of running JS (for an ad, sigh).

The rest seems quite idle, so that suggests that we're scrolling on the main thread (not sure how to tell from the trace).

Once the page is loaded everything scrolls smoothly.

As often happens, on Safari everything is great :/
Not sure if there is anything the scheduler could help with here (+cc-ing some sched folks)
 
trace_ebay_slow.json.gz
5.8 MB Download
I know one of their lead devs well; let me know if an intro would be helpful.
Thanks Alex.

To be honest there seem to be a recurring pattern here (this bug is about ebay, Issue 613795 was JamesPendleton.co.uk,  Issue 539642  was gizmodo).
In all these cases the situation is: scrolling being janky in Chrome while Safari is silk smooth (same page, same machine).
When looking at the traces in most cases the culprit seems to be that we (Chrome) are scrolling on the main thread and janking because the main thread is busy.

I understand that this can be fixed changing the web content and using things like passive listeners, deferring script loading and whatnot. But I start wondering whether we, as a browser, should just be more aggressive (w.r.t scrolling on the compositor thread at the risk of breaking things). The user experience in these cases is just too bad.

I am super glad if we can get ebay to improve their website. I just worry that this approach doesn't scale and we'll keep seeing cases like this every day on other websites.
Yup, agreed that a scalable approach is better. I think no matter what we should understand the problem and try to fix it at scale. I was just offering in case we wanted to understand better what they were trying to accomplish.
Components: Blink>Scheduling
Status: Available (was: Untriaged)
Yep, looks like main thread scrolling. Weirdly I seem to get normal compositor scrolling on Linux here.

Could you try again with --enable-prefer-compositing-to-lcd-text? On a retina mac that shouldn't make a difference but worth a try still.

The other weird thing here is that main thread input events are ending up in the default task queue instead of the compositor task queue. I don't see how that could be happening, but if it is, it would explain some of the slowness.
Labels: -Performance Performance-Responsiveness
Project Member

Comment 6 by sheriffbot@chromium.org, Apr 30 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Available (was: Untriaged)
Checked again, still pretty janky on a Pixelbook.
This should become better with the recent improvements and I can't repro this. Sami, could you try this again on your Pixelbook and attach a trace?
Status: WontFix (was: Available)
Tried on a pixelbook, couldn't repro.

Sign in to add a comment