Surface synchronization should address many/most of these concerns: https://bugs.chromium.org/p/chromium/issues/detail?id=672962 We do not currently have the cycles to turn on surface synchronization on Android. I'm happy to guide an engineer who wishes to use surface sync on Android though. There's a fair amount of refactoring involved here, but it should address many of the concerns here. 

I spoke with Fady today and it looks like there would be a straightforward way to achieve what 4) is doing with surface synchronization. What this patch is trying to achieve using the metadata is the following:

1) A transition is initiated in the browser (fullscreening of an element, resize during fullscreen) that requires synchronization with the renderer's frame. During the transition, we'd rather just cover with a black frame.

2) The property required to be synchronized is pushed through the complete pipeline (render thread tree -> pending tree -> active tree -> CompositorFrame), the metadata has that property bundled with the frame so the browser can know that this is the desired frame. At which point the Surface with this frame is embedded by the browser.

The size is already there on the frame's root pass, the additional bit this patch is adding to the metadata is whether an element was fullscreen in this frame.

With Surface synchronization enabled, instead of reading the metadata to know if all the bits were reflected in a frame, this is what would happen:

1) The browser would generate a new Surface id and add it to the Resize IPC sent to the renderer that takes the fullscreen/size update that we want synchronized. This surface id goes through the pipeline in the same way and gets added to the frame metadata.
 
2) The browser compositor produces a frame that embeds the renderer's frame using this surface id that's submitted to viz, and a fallback surface which for the fullscreen transition would just be a pass with a black solid draw quad (you have to give viz something otherwise it won't activate your frame until the dependency is satisfied).

3) Once it receives the surface id embeded in the browser's frame, it will use that instead.

For synchronization issues where the parent initiates a change it wants to synchronize with the child, using the metadata is consistent with the pattern that surface synchronization is providing. The cases that are concerning are the anti pattern, where the child is initiating a change that affects the parent's frame which is the category top controls and selection handles fall in. And we can not move to surface synchronization until these are resolved.

As for this change, I don't think it is adding a dependency that will be difficult to move to surface synchronization. And given that resolving blockers to enabling it for android is not trivial, we shouldn't block the change on it.

Fady, feel free to add if I misunderstood something.

Makes sense, thanks.  My intent in filing this bug was to make sure we have a plan to transition these flicker fixes to Viz, it sounds like we have formulated such a plan.  I'm only interested in blocking new metadata from being added if they make it qualitatively harder to transition to Viz -- which seems like it's not the case here given surface synchronization is designed to address precisely this use class.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Was fixed in the de-sniffing work? jonross@ to triage.

I think I'm currently the owner for this. 

I believe this is fixed but I'll leave this bug open until surface synchronization hits stable.

We already have a bug tracking surface sync for android so I'll just mark this as fixed.