Set BrowserCompositorOutputSurface's vsync parameters on mac
Mac routes vsync parameters differently than other platforms. Other platforms go directly through BrowserCompositorOutputSurface, which then routes it to the vsync manager (without begin frame scheduling) or just to the root BeginFrameSource for that BrowserCompositorOutputsurface (with begin frame scheduling). Mac is different in that the RenderWidgetHostViewMac gets the vsync info from the DisplayLink, which forwards it to the BrowserCompositorMac. This would then forward that to the ui::Compositor's vsync manager which would then be used to tick the browser and then indirectly would forward to the begin frame source for the BrowserCompositorOutputSurface to tick the display. --enable-begin-frame-scheduling turns off the vsync manager, which previously left the browser and then display compositors to tick at default intervals and timebases on Mac, leading to power regressions. OOPS. This patch adds an additional route where the BrowserCompositorMac forwards vsync info to the BrowserCompositorOutputSurface's BeginFrameSource via ui::Compositor's ui::ContextFactory (aka GpuProcessTransportFactory). As the BrowserCompositorOutputSurface's begin frame source is the source of all frames when using --enable-begin-frame-scheduling, this fixes the regression. Once --enable-begin-frame-scheduling becomes the default, all of the vsync info and vsync manager plumbing can be removed. With this patch, power usage on one test laptop for h264 video when using --enable-begin-frame-scheduling goes from 2.00W -> 2.05W instead of from 2.0W -> 2.3W. R=ccameron@chromium.org Review-Url: https://codereview.chromium.org/2170053002 Cr-Commit-Position: refs/heads/master@{#407632}
Showing
Please register or sign in to comment