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

Issue 658988 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Nov 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Mus: Unify ServerWindowCompositorFrameSink and DisplayCompositorFrameSink

Project Member Reported by fsam...@chromium.org, Oct 25 2016

Issue description

A ServerWindowCompositorFrameSink is a delegating CompositorFrameSink in the sense that it does not do any actual compositing. It holds a SurfaceFactory.

DisplayCompositorFrameSink is a CompositorFrameSink that holds a cc::Display.

In Jellyfish, we unified the two concepts by providing an API to request a CompositorFrameSink(ContentFrameSink) by specifying a SurfaceHandle or AcceleratedWidget. If a CompositorFrameSink provides a non-null SurfaceHandle then it gets a cc::Display. If it does not not, it does not get a cc::Display.

The root window on a Display should provide an AcceleratedWidget when requesting a CompositorFrameSink.

FrameGenerator should be renamed to "DisplayFrameGenerator" and its role is to Submit a CompositorFrame to the root window's CompositorFrameSink. 

DisplayCompositorFrameSink goes away, leaving only one API for CompositorFrameSink in Mus.
 
Adding a bunch of miscellaneous cleanups.

ServerWindowCompositorFrameSink will end up living in mus-gpu, and so it should not have direct access to window server things:

ServerWindowCompositorFrameSink should not refer to ServerWindowCompositorFrameSinkManager (which will go away soonish), and ServerWindow (which lives in mus-ws).

ServerWindowCompositorFrameSink should not refer to anything in services/ui/ws.

FrameGenerator will likely continue to live in the window server, but will be significantly changed in upcoming months. However, this means it cannot refer to ServerWindowCompositorFrameSink directly. Instead, once the root window's CompositorFrameSink is the display CompositorFrameSink, then we should use the same mojo interface that other apps use to add a reference.
Once the split is complete "ServerWindowCompositorFrameSink" becomes a bit of a misnomer. Maybe it can be renamed (yet another rename! YAR! YAR YAR, matey!) to MusCompositorFrameSink!

Comment 3 by sadrul@chromium.org, Oct 25 2016

What are the chances we can use shorter names? :)

Will these frame-sinks be different in salamander with content-frames? If not, how about s/CompositorFrame/Frame/?

Will there be equivalents on the client side? If not, how about s/ServerWindow/Window/?

WindowFrameSink and DisplayFrameSink seems clear enough, and so much shorter than ServerWindowCompositorOnceUponATimeLongAgoFrameSink.
Yes, I suspect we'll have ContentFrameSinks and CompositorFrameSink. We already have WindowCompositorFrameSink in the client lib. ServerWindowCompositorFrameSink is the server-side code.
ServerWindowCompositorFrameSink depends on ServerWindow for two reasons:

1. window()->delegate()->OnScheduleWindowPaint(window()); which is mus' adhoc damage tracking to trigger a new frame. Once Mus uses BeginFrames then this no longer becomes necessary.

2. FrameGenerator::AddOrUpdateSurfaceReference uses it. This can be solved by instead passing in a ServerWindow + CompositorFrameSinkType. Since this is easy to do now, I'll send out a CL shortly.

Once those two are out of the way, then we can introduce a DisplayCompositor::CreateCompositorFrameSink API, and merge DisplayCompositorFrameSink and ServerWindowCompositorFrameSink.
Project Member

Comment 6 by bugdroid1@chromium.org, Oct 27 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fadcdb0baa1441b4f0ddf1e80e456079b926a357

commit fadcdb0baa1441b4f0ddf1e80e456079b926a357
Author: fsamuel <fsamuel@chromium.org>
Date: Thu Oct 27 22:56:49 2016

Mus: Remove dependency on ServerWindowCompositorFrameSink from FrameGenerator

FrameGenerator will live in mus-ws but ServerWindowCompositorFrameSink
will live in mus-gpu. Thus, we should not access it directly.

ServerWindowCompositorFrameSinkManager now serves as a cache of state
from CompositorFrames submitted to mus-gpu. FrameGenerator looks up
that state in ServerWindowCompositorFrameSink.

BUG= 658988 

Review-Url: https://codereview.chromium.org/2453013002
Cr-Commit-Position: refs/heads/master@{#428182}

[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/frame_generator.cc
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/frame_generator.h
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/frame_generator_unittest.cc
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/server_window_compositor_frame_sink.cc
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/server_window_compositor_frame_sink.h
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/server_window_compositor_frame_sink_manager.cc
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/server_window_compositor_frame_sink_manager.h
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/server_window_compositor_frame_sink_manager_test_api.cc
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/window_server.cc
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/window_server_test_impl.cc
[modify] https://crrev.com/fadcdb0baa1441b4f0ddf1e80e456079b926a357/services/ui/ws/window_tree.cc

2 is fixed: FrameGenerator no longer depends directly on ServerWindowCompositorFrameSink::window()

1.  window()->delegate()->OnScheduleWindowPaint(window()) should go away once FrameGenerator receives BeginFrames. (soonish)
Project Member

Comment 9 by bugdroid1@chromium.org, Nov 2 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb

commit d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb
Author: fsamuel <fsamuel@chromium.org>
Date: Wed Nov 02 15:50:52 2016

Mus+Ash: Unify CompositorFrameSinks

This CL moves towards enabling unified BeginFrame in Mus and splitting
the display compositor out of the window server.

1. FrameGenerator now submits CompositorFrames to the root window's
CompositorFrameSink instead of a special "DisplayCompositorFrameSink".
2. ServerWindowCompositorFrameSinks that have a valid AcceleratedWidget
will get a cc::Display (this should become SurfaceHandle when ready).

In an upcoming CL, FrmaeGenerator will no longer need to be aware of
GpuChannelHost. Instead it will simply use the root window's
CompositorFrameSink as is.

BUG= 658988 

Review-Url: https://codereview.chromium.org/2471503002
Cr-Commit-Position: refs/heads/master@{#429286}

[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/surfaces/BUILD.gn
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/surfaces/direct_output_surface.h
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/surfaces/direct_output_surface_ozone.h
[delete] https://crrev.com/c08c078b27b353f4ab8de7deccfb862270b1ff2a/services/ui/surfaces/display_compositor_frame_sink.cc
[delete] https://crrev.com/c08c078b27b353f4ab8de7deccfb862270b1ff2a/services/ui/surfaces/display_compositor_frame_sink.h
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/surfaces/surfaces_context_provider.h
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/BUILD.gn
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/frame_generator.cc
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/frame_generator.h
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/server_window.cc
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/server_window.h
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/server_window_compositor_frame_sink.cc
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/server_window_compositor_frame_sink.h
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/server_window_compositor_frame_sink_manager.cc
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/server_window_compositor_frame_sink_manager.h
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/window_tree.cc
[modify] https://crrev.com/d2f1931ecdde26742abf7cc23f79b38d1dfaf7fb/services/ui/ws/window_tree.h

Owner: fsam...@chromium.org
Status: Fixed (was: Untriaged)

Sign in to add a comment