Handle top bar controls with Surface Sync / Viz on Android |
|||||||||||||||||
Issue descriptionChrome for Android top bar controls looked like a complex special case that would make refactoring cc/surfaces for Mus difficult so I was hoping to de-special-case some of this. My understanding of the code is currently, we send input events to the renderer, which scrolls, and sends an offset to slide the top bar controls in CompositorFrameMetadata. The browser then deals with positioning the top bar controls when it receives the CompositorFrame. You can imagine in a future world where the display compositor moves to the GPU process, this doesn't make sense. https://cs.chromium.org/chromium/src/cc/output/compositor_frame_metadata.h?type=cs&q=CompositorFrameMetadata&l=59 Since the renderer can set the position of the top bar controls, it's conceivable that it could already put the top bar controls entirely offscreen, and display its own version to the user, fooling them into believing they're at a different site. My suggestion is then, to avoid some special casing, the browser simply sends the renderer the surface ID for the top bar controls and lets the renderer scroll the top bar controls. Surface IDs are opaque identifiers. They're not pixels and so readback is not possible. It seems like the security model here is similar to what we already have and this could simplify the code quite a bit.
,
Feb 27 2017
,
Apr 12 2017
This is likely blocked on surface synchronization: 1. Browser submits a CompositorFrame corresponding to the top bar controls with a given LocalSurfaceId. The SurfaceId = (FrameSinkId, LocalSurfaceId) pair that is then passed to the renderer. With an out-of-process "display compositor", that message will not be delivered to viz (the new name for the gpu process) immediately. 2. The browser sends the SurfaceId for the top bar controls to the renderer. 3. The rendrerer embeds that surface ID and submits a CompositorFrame. If 3 arrives to the display compositor before 1 then we'll have missing content. Surface synchronization will take care of this by blocking activation of the renderer's CompositorFrame until the top bar controls have been received by the display compositor.
,
Apr 13 2017
We allocate a new local surface id not only on top and bottom bar changes but also when selection and has_transparent_background change. Can someone explain why we do that? Is that actually necessary? https://cs.chromium.org/chromium/src/content/renderer/gpu/renderer_compositor_frame_sink.cc?rcl=cceb830695c05acfa0c6a4fbcba8ecf8efb9551e&l=193
,
Apr 13 2017
My guess would be to sync up with touch selection handles but that's just a guess?
,
Apr 30 2017
,
Jun 12 2017
,
Jun 12 2017
,
Jun 13 2017
,
Oct 26 2017
,
Nov 15 2017
Per offline discussion, it seems like a slightly different approach may better handle the security concerns around Omnibox positioning. See the doc here: (see doc here: https://docs.google.com/document/d/1nawFPSv7FMT1FjZ5rbm4aBVIfGND7ZtVZWSqVJe01L0/edit#) To summarize: 1) If the renderer requires a browser UI update, it generates a new Surface ID and sends this surface ID with metadata to the browser. 2) The renderer sends its compositor frame (using the new surface ID) to the Viz/GPU proc. 3) The Browser generates a new compositor frame with elements updated according to the metadata. This frame embeds the new renderer surface ID. This compositor frame is sent to the Viz/GPU process. 4) Viz/GPU process composites the visual output using GL. The main challenge with this approach is that we need a new system which allows a renderer to generate new surface IDs (for step 1).
,
Nov 15 2017
,
Nov 21 2017
,
Feb 8 2018
,
Feb 8 2018
,
Feb 13 2018
,
May 15 2018
,
May 25 2018
Assigning myself and marking as FIXED as top bar controls now use surface sync. |
|||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||
Comment 1 by aelias@chromium.org
, Feb 8 2017