Currently, CompositorFrames submitted for a given LocalSurfaceId have a bag of properties which must be negotiated between the child/parent. These include:
- Resize params such as Size, DSF, Colorspace, and whether AutoResize is enabled
- Metadata such as top bar positioning and selection handle positioning.
The parent/child must agree on all these properties for the parent to successfully embed / display the child.
Unfortunately, resize params are currently negotiated on the Renderer's main thread, while Metadata such as top bar positioning and selection handle positioning is resolved / sent from the renderer's impl thread. This makes coordinating the two sets of properties difficult.
To resolve this, the following system could be used:
1) Size changes due to autoresize are propagated from the main thread to the impl thread as though they will succeed. The impl thread must be aware that a size change is due to a renderer-driven autoresize (not a browser-driven resize). No autoresize messages will be sent from the renderer main thread to the browser.
2) The renderer impl thread will combine the current resize params with its current top bar and selection handle positioning.
3) If any param changed due to a *renderer-intiated* change (autoresize, metadata change), the renderer will generate a new LocalSurfaceId and send the full set of parameters to the browser along with this ID.
4) The renderer will then proceed to submit a frame with the new ID.
5) The browser will consume the new params and surface ID, embedding it in the next frame it produces.
Note that some params (size) may be changed by either the renderer or the browser. Param resolution happens as follows:
Size - If AutoResizeenabled, Renderer wins, otherwise Browser wins
DSF - Browser wins
Colorspace - Browser wins
AutoresizeEnabled - Browser wins
Top Bar Position - Renderer wins
Selection handles - Renderer wins
Because these params can always be cleanly resolved (multiple round trips are not needed to negotiate), the Browser or Renderer can always accept the new SurfaceId / params from the other.
Comment 1 by ericrk@chromium.org
, Feb 13 2018