Surface synchronization: Consider interaction with cc::Scheduler and layer compositor |
||||||||||||
Issue descriptionThe layer compositor has a low latency mode and a high latency mode. In high latency mode, 3 frames can be in flight at a given time (brianderson@, is that correct)? During resize, that entire pipeline needs to be flushed because layout changes on resize. Thus, a lot of wasted work is happening here. Can we turn off high latency mode during surface sync? One thing to investigate is if we can signal to the scheduler that surface IDs are changing rapidly (as a proxy to resize) and so we should switch to low latency mode.
,
Apr 3 2017
Define "frames" and "in flight" here, please.
,
Apr 3 2017
Disclaimer: I don't have a deep understanding of the code yet. My understanding from brianderson@ in high latency mode, we can be doing main thread work, "compositing" work and raster work for a layout that is likely to change soon. This is wasted work, right?
,
Apr 3 2017
Set Available/Feature on this type of tracking issue so we don't have to go through them in our triage.
,
Apr 20 2017
,
May 3 2017
,
May 3 2017
We're planning to add a flush pipeline mode to the scheduler for headless chrome. I haven't flushed out all the details yet but it will probably be a flag on the begin frame args. For cc scheduler it means completing any pending commits and activations (skipping draws) and then waiting until the main thread produces a new commit and activation. Only after that can we draw. ofc the display scheduler also has to run any pending draw callbacks (force activate pending frame?) so that the renderer is unblocked. I think this mode would make a lot of sense for resizing.
,
May 3 2017
,
May 5 2017
,
May 23 2017
,
Jun 13 2017
,
Jul 21 2017
,
Nov 7 2017
,
Aug 25
-> fsamuel@ for triage/WontFix
,
Sep 10
I'm marking as WontFix for now. This might come up again but for now we're not actively pursuing it. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by fsamuel@google.com
, Apr 1 2017