New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 810213 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Blocked on:
issue 811944

Blocking:
issue 801350
issue 689754
issue 713696



Sign in to add a comment

Move renderer LocalSurfaceId allocation to Impl Thread

Project Member Reported by ericrk@chromium.org, Feb 8 2018

Issue description

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

Blockedon: 811944

Comment 2 by cblume@chromium.org, Apr 23 2018

Cc: -fsam...@chromium.org cblume@chromium.org
Owner: fsam...@chromium.org
Fady is working on this now.
Status: Fixed (was: Assigned)
This is actually done.

Sign in to add a comment