Continuous BeginFrame notifications on Instagram |
||||||
Issue descriptionChrome Version: 60.0.3108.0 OS: Win10, other OS possibly too. What steps will reproduce the problem? (1) Navigate to https://www.instagram.com/intel/ (2) Wait until the page goes idle (3) Capture traces (make sure to include "cc" and "gpu" categories) What is the expected result? No activity in the compositor / renderer / gpu What happens instead? It doesn't look like any new frames are rendered (no events in GPU process), but it appears the renderer process keeps handling BeginFrame continuously at 60 fps. I debugged this and verified that CompositorFrameSinkSupport::OnBeginFrame is called continuously (in the browser process). From there it seems BeginFrame gets dispatched to the renderer process. CompositorFrameSinkSupport is the only observer of BeginFrameSource when the page is idle. This results in ~1000 idle wakeups per second on a seemingly static page content.
,
May 27 2017
I've attached the trace. I've also did a performance profile (using dev tools). It looks like RAF gets continuously fired so perhaps that the reason BeginFrame is needed in the first place - see the attached screenshot.
,
May 27 2017
Actually attaching the trace.
,
May 30 2017
From what I see it isn't limited to continue scrolling pages like instagram and twitter where we first noticed this but it also looks like to a lesser extent it appears on pages like amazon https://www.amazon.com/Winter-Is-Coming/dp/B007BVOEPI/ref=sr_1_1?ie=UTF8&qid=1490289478&sr=8-1&keywords=Game+of+Thrones where we see and extra 2 Compositor - OnBeginFrame calls on a seemingly static page as the one listed above. Rich
,
May 30 2017
fsamuel@: Does this look like the same bug that you fixed in https://codereview.chromium.org/2887453002 ?
,
May 30 2017
,
May 31 2017
The browser is not sending unsolicited BeginFrames to the renderer. The renderer asks for it, and submits frames in response (though not for every BeginFrame). It claims there is damage near the sign up button at the bottom although I don't see any changes in that area. This could be bug but probably not related to Fady's change.
,
May 31 2017
A couple of notes: 1) I did some debugging and can confirm that demand for BeginFrames comes from javascript calling Document::RequestAnimationFrame. The page seems to be doing that continuously. 2) The repro requires logging into an account so there is no sign up button at the bottom in my case. I don't know if we can do anything in this case. It looks like this works as intended.
,
Jun 12 2017
I'll take this and investigate this a bit further.
,
Nov 1 2017
Changing status to untriaged. I won't be able to work on this. This behavior seems to be by design because the page continuously requests animation frame but doesn't do anything with it. So perhaps this should be resolved "Won't fix".
,
Nov 3 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by piman@chromium.org
, May 24 2017Status: Available (was: Untriaged)