Renderer is actively rendering but the tab content never changes |
||||||||||
Issue descriptionChrome 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.
,
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)?
,
Feb 22 2017
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?
,
Feb 22 2017
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.
,
Feb 22 2017
,
Mar 10 2017
No feedback so WontFix. This is almost certainly a hit testing performance duplicate.
,
Jul 6 2017
> 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).
,
Jul 7 2017
You might be seeing the cost of determining that nothing in view is invalidated. Others can probably explain this better than me.
,
Jul 7 2017
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.
,
Jul 10 2017
> 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
,
Jul 18 2017
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 |
||||||||||
Comment 1 by cbiesin...@chromium.org
, Feb 21 2017