New issue
Advanced search Search tips

Issue 764732 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 771138

Blocking:
issue 730193



Sign in to add a comment

Implement a DisplayProvider for content, and pull out viz::Display init code out of GpuProcessTransportFactory

Project Member Reported by fsamuel@google.com, Sep 13 2017

Issue description

Most of the code in GpuProcessTransportFactory belongs in the Viz service including creation of the viz::Display, the BeginFrameSource, and the
OutputSurface.

We should create a new DisplayProvider that moves that functionality
out of GpuProcessTransportFactory. That DisplayProvider is then passed
into FrameSinkManagerImpl's construction.

The end state of this work is DirectLayerTreeFrameSink goes away, and instead content uses RootCompositorFrameSinkImpl for UI. Initially,
we may not use a Mojo MessagePipe but we will still use raw pointers
to mojo interfaces in UI.
 

Comment 1 by fsamuel@google.com, Sep 13 2017

Blocking: 730193
Blocking: 770833
Blockedon: 771138
Owner: ----
Status: Available (was: Assigned)
Not working on this currently.

Comment 5 by danakj@chromium.org, Oct 25 2017

Is this WontFix cuz you're doing this another way?
Blocking: -770833
This is potentially a WontFix. It's an intermediate step between how things work today and how --enable-viz would work. If we move straight an out of process display compositor we don't need the intermediate step.
Status: WontFix (was: Available)

Sign in to add a comment