New issue
Advanced search Search tips

Issue 693775 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: 1
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Renderer is actively rendering but the tab content never changes

Project Member Reported by shrike@chromium.org, Feb 17 2017

Issue description

Chrome Version: (copy from chrome://version)
OS: (e.g. Win7, OSX 10.9.5, etc...)

What steps will reproduce the problem?
(1) Navigate to www.politico.com
(2) Wait for ad animations to complete

What is the expected result?
Renderer process should not render any content.

What happens instead?
JavaScript tracing shows that the renderer is actively rendering (you can see composite layers, paint, render events), but QuartzDebug shows there are no changes making it to the screen.

I assume this is happening across desktop but only checked the Mac.


 
trace_politico.json.gz
2.4 MB Download
politico-TimelineRawData-20170217T145622.json
14.4 MB View Download
Components: -Blink Internals>Compositing
I guess this would be a compositing issue...

What Chrome version are you using? I see you left that field blank. Also can you paste the contents of chrome://gpu?

Comment 2 by shrike@chromium.org, Feb 21 2017

Sorry about that - it looks like I was using 56.0.2924.87.

Is it really a compositing issue? Or should the blink side of the world be taking an early-out somewhere (because the end result is no change on the screen)?


gpu.html
59.1 KB View Download

Comment 3 by ericrk@chromium.org, Feb 22 2017

Components: -Internals>Compositing Blink>Paint
Looking at the compositor and rasterization threads, we aren't actually doing any rasterization or compositing - we keep aborting frames as there are no updates to display.

It looks like the majority of work is happening on the main thread in blink - my guess is that something on the page causes blink to re-paint, but in such a way that we don't end up with visible damage, so nothing happens in the compositor.

Not sure that this is a bug, or the page is just updating the DOM constantly in a non-visible way?
EstimatedDays: 1
Labels: Needs-Feedback
NextAction: 2017-03-06
Status: Unconfirmed (was: Untriaged)
In M57 on Linux we are doing some work on every frame, but it's for hit testing as the mouse moves (due to hover events and other things requiring knowledge of what's under the cursor). Hit testing exercises painting related code and requires updated layout and style etc.

The hit testing of certain content is known to be expensive and we already have bugs filed on that.

I'm inclined to WontFix, but first ...

When you say that you are seeing paint events, are you saying that the "Paint Flashing" mode in the Renderign section on devtools is showing repaints?

And note the typo in the original report. This is politico.com, not politco.com.
Description: Show this description
Status: WontFix (was: Unconfirmed)
No feedback so WontFix. This is almost certainly a hit testing performance duplicate.
Status: Untriaged (was: WontFix)
> When you say that you are seeing paint events, are you saying that the "Paint Flashing" mode in the Renderign section on devtools is showing repaints?

I'm saying that if you look at the JavaScript trace I attached as part of the original report, DevTools shows that there is paint and render activity. This activity is occurring even though no new bits are drawn to the screen (which I confirmed using QuartzDebug).
Screen Shot 2017-07-06 at 9.28.31 AM.png
47.6 KB View Download
Cc: chrishtr@chromium.org wangxianzhu@chromium.org
Labels: -Needs-Feedback BugSource-Chromium PaintTeamTriaged-20170707
Status: Available (was: Untriaged)
You might be seeing the cost of determining that nothing in view is invalidated.

Others can probably explain this better than me.
Status: WontFix (was: Available)
Just because you can't see pixels change does not mean the app is not dirtying
renderer state. The app is constantly making changes to the DOM state which happen to result in no pixels changing. But for Blink to figure that out requires running the
rendering pipeline.
Labels: -PaintTeamTriaged-20170707
Status: Untriaged (was: WontFix)
> But for Blink to figure that out requires running the rendering pipeline.

I can imagine this sometimes being the case, but is it really true here? In Chrome 61.0.3153.0, the renderer consumes ~4.6% CPU while the Safari renderer uses just 1.3%, so Chrome is 350% of Safari. The JavaScript profiler in Chrome shows scripting, rendering, and painting activity, but the profiler in Safari only shows scripting. I know that Blink and WebKit diverged awhile ago, but is it really the case that Blink has to fire up its rendering pipeline to determine something that WebKit can apparently early out of?

Link to archived politico site: https://drive.google.com/open?id=0BwcLL5PHtZQHNTMyQ0xYdVVsS1E

Labels: PaintTeamTriaged-20170707
NextAction: ----
Owner: schenney@chromium.org
Status: Assigned (was: Untriaged)
We need to profile this to see what the cost is and whether we might be able to optimize it. I'm doubtful.

Sign in to add a comment