Investigation into Scheduling.Browser.DrawInterval spike on macOS |
||
Issue descriptionNov 25, 2015: brianderson@ adds metric Scheduling.Browser.DrawInterval (d32468dc9c5427126d519ac320167ffe77ecb7da). Intended purpose: Measure frame rate of browser UI updates (e.g. top chrome for Aura based browsers). Known flaw: The metric is only emitted if frame production >= frame consumption. This means that a spike in metric average/median could actually be a net improvement, if the total number of output samples has gone down. Known flaw: Author did not think that this metric would be emitted on macOS. The exact meaning is unclear. The metric is first seen on the macOS Beta channel on 1/28/2016. Feb 29, 2016: erikchen@ merged IOSurface clearing to branch 2623 (f3c181bd45aa0f79041ab2b79aece0021423aee5). This appears to be loosely correlated with a spike in Scheduling.Browser.DrawInterval on macOS 10.10, Beta channel. Aug 4, 2016: erikchen@ disables IOSurface clearing on macOS 10.10, unconditionally (46fca07f8d54fdcd5188920f5be1b8b8c1860ac2) (M54). Note that Scheduling.Browser.DrawInterval is still elevated even after first M54 Beta release comes out.
,
Sep 14 2016
Currently looking into Scheduling.Browser.DrawInterval: RenderWidgetHostViewMac creates BrowserCompositorMac creates RecyclableCompositorMac creates ui::Compositor creates LayerTreeHost::CreateSingleThreaded creates SingleThreadProxy creates Scheduler CompositorTimingHistory It appears that when windows are resized, when tabs are created, and when a page is first loaded, Scheduler::DrawAndSwapIfPossible gets called, which sometimes emits in the metric in question. However, scrolling a page via RAF or gesture does not emit this metric. Still investigating to understand why Scheduler::DrawAndSwapIfPossible is only sometimes called, and whether it has any effect at all.
,
Sep 14 2016
I'm pretty sure that Scheduling.Browser.DrawInterval is vestigial on macOS. Perhaps before UBF and the Surfaces refactor, this code might have meant something. The BeginFrameSource for the renderer's cc::Scheduler is basically a cross-process proxy to a DelayBasedTimerSource owned by a cc::Display in the browser process. When the renderer sends new CompositorFrames, they get processed by the DelegatedFrameHost/surfaces code. Note that the browser cc::Scheduler is not involved in any of this, as expected from the surfaces refactor. The only time the cc::Scheduler is not idle is shortly after a page load, and during window resizes. I suspect that the only reason the browser cc::Scheduler needs to be present at all is to make sure that the LayerTreeHost's root layer [which is empty but is the parent of the DelegatedFrameHost layer] gets sized appropriately.
,
Sep 14 2016
Nothing more to be done here. The fact that Scheduling.Browser.DrawInterval is emitted on macOS implies there are weird inefficiencies in the Browser cc::Scheduler. |
||
►
Sign in to add a comment |
||
Comment 1 by erikc...@chromium.org
, Sep 14 20161.1 MB
1.1 MB View Download