> The browser process can then use a DelegatingRenderer and a mus::OutputSurface to submit its "display" CompositorFrame to mus.

Can you explain this?

ui::Compositor is already using a DelegatingRenderer, so no change there right?

There's some decoupling of the SurfacesOutputSurface that the ui::Compositor uses from the BrowserCompositorOutputSurface that the display compositor uses. And give the SurfacesOutputSurface an IPC/mojo backend.

The ""display" CompositorFrame" is leaving me unsure what you mean. The display compositor isn't going to use a DelegatingRenderer right? You're moving the display compositor out of process? It could live in mus or the gpu process, really, depending on your configuration.

This is a temporary step to get full accelerated compositing of Chrome in Mus+Ash without making Chrome renderers mus::Windows and all the input handling involved (a bunch of in-progress work). Until that is done, we'd like all of Chrome to be a mus::Window. 

The idea is there would be two cc::Displays: one in Chrome and one in Mus. That way, the final CompositorFrame in Chrome (post SurfaceAggregator::Aggregate) would get submitted to Mus. Mus would create its own Display CompositorFrame that includes the Chrome OS UI and other windows.

So, half the idea of getting rid of DirectRenderer in LayerTreeHostImpl is to get rid of the concept of DelegatingRenderer entirely. This proposal requires OutputSurface to support all the things it does now etc. It feels like we're re-introducing dependencies preventing us from going the direction we want to go in compositor-land, with the work to make LTHI always CompositorFrameSink and Display always OutputSurface.

What other options might we have? Why do you need mus::Windows involved here just because the Display is in the process and it's receiving IPCs with CompositorFrames to give to the SurfaceAggregator?

Rob and I had a long chat about this. We think we can introduce a mojo CompositorFrameSink abstraction to mus sooner rather than later that is decoupled from mus::Window, and have mus-gpu receive CompositorFrames from all clients. That way we don't need to use DelegatingRenderer in the browser. I'll keep this bug open to track progress towards that.

Adding displaycompositor and gpurefactor labels to this bug as it related to both.

I thought some more about this and submitting CompositorFrames to mus directly from the renderer currently has hit testing implications. Instead what I might do is have the Chrome renderer submit CompositorFrames to the browser by conventional means and in each DelegatedFrameHost, if running in Mus, that CompositorFrame is forwarded to Mus. it's definitely not ideal but at least the SurfaceAggregator and Display is only running in Mus and not Chrome. WDYT, Dana?

Argh, turns out there's some more complexity here. SurfaceFactory, SurfaceManager, etc live in Mus, so SurfaceHittest (which needs SurfaceManager for surface ID lookup) won't work out of the box. Would you oppose the first approach with the expectation of that code path going away by end of quarter, or early next quarter once input processing is "good enough"?

per the musgpu/musws split where "delegated windows" need to do hit testing in another process, why can't (temporarily) the musws ask the browser to deal with the hit detection? Or does that require us to ship the CFs to browser and mus?

For the browser to do hit testing then the browser must get the CompositorFrames

> Would you oppose the first approach with the expectation of that code path
> going away by end of quarter, or early next quarter once input processing is
> "good enough"?

It's just you're trading progress on one front by stalling progress on another. And you're going to have to solve the problems that are causing this situation anyways. So it feels like you have the order wrong to me.

There was some talk about exploring Mac OSX/CoreAnimation to draw parallels and help inform us what we should do about hit testing. Maybe we should be sorting that out first, and looking at options like input latching instead of surface hit testing to see if it's viable.

Marking as WONTFIX because we have a different approach implemented.