scrolling ebay on mac unacceptably janky while loading |
||||||
Issue descriptionCanary (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)
,
Jul 20 2016
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.
,
Jul 20 2016
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.
,
Jul 25 2016
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.
,
Apr 29 2017
,
Apr 30 2018
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
,
May 9 2018
Checked again, still pretty janky on a Pixelbook.
,
Aug 16
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?
,
Oct 2
Tried on a pixelbook, couldn't repro. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by komoroske@chromium.org
, Jul 19 2016