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

Issue 689696 link

Starred by 5 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocking:
issue 732572



Sign in to add a comment

Unify OutputSurfaces and centralize DisplayCompositor

Project Member Reported by fsam...@chromium.org, Feb 7 2017

Issue description

services/ui/surfaces/display_compositor.cc is the thing that owns SurfaceManager in Mus currently and is a SurfaceObserver. It is informed when Surfaces are created and forwards that to the display compositor host (in Mus+Ash, that's the window server). DisplayCompositor also implements the mojom::DisplayCompositor interface that allows creating CompositorFrameSinks.

DisplayCompositor is responsible for creating a cc::Display and an OutputSurface.

We should try to unify all this code across Chrome and Mus+Ash. In particular, Mus has partial implementations of DisplayOutputSurface and DisplayOutputSurfaceOzone. We should look into unifying those with BrowserCompositorOutputSurface and GpuBrowserCompositorOutputSurface maybe.

All this code should live in components/display_compositor. OffscreenCanvasCompositorFrameSinkProviderImpl should probably go away and be replaced by DisplayCompositor.

In Chrome, GpuProcessTransportFactory can own a DisplayCompositor.
 
Status: Available (was: Untriaged)
I'm working towards using DisplayCompositor in GpuProcessTransportFactory today in Chrome. https://codereview.chromium.org/2688593002/

Comment 3 by xing...@intel.com, Feb 20 2017

Cc: xing...@intel.com
Labels: Type-Feature
Owner: kylec...@chromium.org
Status: Assigned (was: Available)
Assigning to kylechar@ since this overlaps between ozone-y and compositing things. 
Cc: weiliangc@chromium.org
Cc: varkha@chromium.org
Labels: -Pri-3 Pri-2
Blocking: 730193
Blocking: -730193
Owner: ----
Status: Available (was: Assigned)
Summary: Unify OutputSurfaces and centralize DisplayCompositor (was: [meta] Unify OutputSurfaces and centralize DisplayCompositor )
It seems that this is cleanup of technical debt, to merge implementations of OutputSurface. We have versions that are for browser-process display compositor (ie BrowserCompositorOutputSurface and children) and some for viz-process display compositor (ie DisplayOutputSurface). We should make the process-specific differences clear and share everything that isn't.

This will be very helpful for ensuring feature parity and sorting out platform-specific details on the way to shipping viz-process display compositor.
Another task here is just moving OutputSurface impls out of content/ to components/viz/, but in-process-in-thread display compositor specific details are content-specific so we'd need to do the above first.
Cc: jbau...@chromium.org vmi...@chromium.org vollick@chromium.org
 Issue 601865  has been merged into this issue.
Blocking: 732572
Why does this block shipping on desktop?
Blocking: -601863
We cannot ship until we have fully functional OutputSurfaces in viz.
Components: -Internals>MUS
Status: WontFix (was: Available)
We have almost entirely rewritten OutputSurfaces for VizDisplayCompositor and will just delete the old versions afterwards, so I think this is WontFix?

Sign in to add a comment