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

Issue 601869 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocked on:
issue 884805

Blocking:
issue 732805
issue 581462
issue 762512



Sign in to add a comment

Reflector should be rewritten in terms of cc::Surfaces

Project Member Reported by fsam...@chromium.org, Apr 8 2016

Issue description

Reflector currently uses ui::Layer and ui::Compositor which Mus will likely not use. Likely, Reflector should be rewritten in terms of surfaces.

 
Blocking: 601863
Components: MUS
Labels: mustash1 displaycompositor mustash mus OS-All
Owner: rjkroege@chromium.org
Status: Assigned (was: Untriaged)
Components: Internals>MUS
Labels: Proj-Mustash
rjkroege: Do we feel this is a blocker for Mus+Ash or a nice-to-have?
Cc: kylec...@chromium.org
kylechar@ and I chatted about how to do this. It's surprisingly easy!

We can introduce 

FrameGenerator::SetMirrorDisplay(...) which will change the behavior of "GenerateCompositorFrame" to instead generate a SurfaceDrawQuad that refers to another display's CompositorFrame.

There are plenty of corner cases:

What if device scale factors don't match?
What if the two displays don't match in size?
What if the vsyncs don't match?
What happens if you remove a monitor while mirroring?
What happens if you add a monitor while mirroring?
Components: -MUS
Labels: -mus -mustash1 -OS-All -mustash -displaycompositor -Proj-Mustash Proj-Mustash-Chrome Proj-Mustash-Milestone-Tadpole Proj-Mustash-Mus-WS OS-Chrome
I like this idea. But... the corner cases are what make it interesting / hard.

And: it's conceivable that the existing code could be made to work in Mash? We should investigate that too.
Possibly, but it seems like mirroring is a properly of display server and not a property of the window manager? Sticking the code in FrameGenerator is closer to the right architecture IMO.
fsamuel@: I agree. I merely noted that it's possible that we could get the reflector operating sooner by re-using the existing code. In the long term, mirroring is definitely something that should be implemented entirely in mus.
s/properly/property
Blocking: 581462
Blocking:

Comment 13 by sky@chromium.org, Mar 27 2017

Labels: mustash-2

Comment 14 by sky@chromium.org, Apr 24 2017

Labels: -Pri-3 Pri-2
Owner: kylec...@chromium.org
We will likely need this for mushrome...maybe we can use layers if it turns out to be too much work, but I'd like us to consider this.
Blocking: 730193
Should we leave this available, this isn't being poked at yet right?
I have been working on it a bit over the last week.
Status: Started (was: Assigned)

Comment 19 by sky@chromium.org, Jun 8 2017

Blocking: 731255
Blocking: -601863
Blocking: -730193 -731255 732805
Owner: ----
Status: Available (was: Started)
Components: -Internals>MUS Internals>Services>WindowService
Blocking: 762512
Labels: -Proj-Mustash-Mus-WS
Deprecating label Proj-Mustash-Mus-WS in favor of Components.
Cc: sky@chromium.org
Status: WontFix (was: Available)
I don't think we need this for Viz. How to make reflector work for OOP-ASH is a different matter. I'm going to close this bug. There should be a different bug tracking reflector for OOP-ASH.

Components: -Internals>Services>WindowService Internals>Services>Viz
Status: Available (was: WontFix)
Isn't it needed for OOP-D on Chrome OS? Reflector doesn't work with OOP-D, and is needed for display mirroring.
Labels: -Proj-Mustash-Chrome Proj-Mash-MultiProcess
This is needed for mash. I don't know enough the bug history to say if it should be this bug, or a new one. If this bug is closed and a new one filed, please tag with Proj-Mash-MultiProcess.
Owner: kylec...@chromium.org
Status: Assigned (was: Available)
It's actually needed for oop-d on CrOS. kylechar@ is working on it.
Blockedon: 884805

Sign in to add a comment