New issue
Advanced search Search tips

Issue 685841 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Main thread scrolling Gmail on low end device swamped by paint invalidation and compositor work

Project Member Reported by esprehn@chromium.org, Jan 26 2017

Issue description

What steps will reproduce the problem?
(1) Load Gmail.
(2) Scroll up and down with the track pad.

The raf callbacks take 1ms, style/layout take 1.5ms combined. The paint invalidation + compositing + picture record + commit lock takes 17ms.

There's also multiple hit tests per frame which seem to each do a compositing update which again takes 3-7ms (depending on if the raster thread deschedules main).

The commit lock blocks main for up to 2ms every frame.

We spend 10ms CPU time (closer to 13ms real) on the raster thread playing back commands for Ganesh. Then we spend maybe 6ms inside the GPU process actually running commands out of the buffer.
 
trace_gmail-scrolling-wizpig.json.gz
2.8 MB Download
trace-wizpig.png
140 KB View Download
Cc: flackr@chromium.org
Owner: chrishtr@chromium.org
Status: Assigned (was: Untriaged)
What is a low-end device in this context?

I think we need to talk to gmail here. Anyone have a gmail contact? What happens on this device if you modify the scrolling div to contain: paint?

We could decide to sacrifice LCD text for scrolling performance on low-end devices. That decision needs to be escalated, and I don't know (a) how we would detect "low-end" or (b) whether we can have different command line flags for different devices (I presume we can).

Assigning to chrishtr@ to manage the external discussions, or delegate.

Comment 3 by flackr@chromium.org, Jan 27 2017

With contain: paint we do promote the email list in M56, scrolling on the compositor and maintain LCD text. I have brought this up but as I understand there is some hesitation because  issue 648091  was not resolved in M55 so adding contain: paint to a composited scroller can break the rendering on high dpi devices running M55.

Even though we can composite the scrolling on this particular page, it seems bad that the main thread path is so expensive.
Also every hit test still has to do all of this work, and any time the app touches the DOM. So while we can paper over the scroll slowness with composited scrolling it doesn't fix the real issue.
Status: WontFix (was: Assigned)
I'm going to go ahead and close this. We are aware of several problem areas that
should help this situation, and various 2018 OKRs, but having a bug just for this
site is not adding extra value right now.

Sign in to add a comment