Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces with embeded content.

Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943, 669964
Committed: https://crrev.com/a86d0169243b98b51554dcdbad647a24ea782aeb
Cr-Commit-Position: refs/heads/master@{#441492}

[mfomitchev, 2016-12-16 20:46:29]

mfomitchev@chromium.org changed reviewers:
+ sky@chromium.org

[mfomitchev, 2016-12-16 20:54:30]

The CQ bit was checked by mfomitchev@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-16 20:55:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-16 21:06:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-16 21:06:32]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[sky, 2016-12-16 21:50:29]

https://codereview.chromium.org/2580063002/diff/1/services/ui/ws/server_windo...
File services/ui/ws/server_window_compositor_frame_sink_manager.cc (right):

https://codereview.chromium.org/2580063002/diff/1/services/ui/ws/server_windo...
services/ui/ws/server_window_compositor_frame_sink_manager.cc:31:
waiting_for_initial_frames_ = !IsCompositorFrameSinkReadyAndNonEmpty(
Can we replace waiting_for_initial_frames_ with
IsCompositorFrameSinkReadyAndNonEmpty(DEFAULT)?

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus.cc
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus...
ui/aura/mus/window_port_mus.cc:211: void
WindowPortMus::UpdateSurfaceLayer(SurfaceInfo* surface_info) {
const SurfaceInfo?

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus...
ui/aura/mus/window_port_mus.cc:212: if (!surface_info)
When and why would null be passed in?

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus.h
File ui/aura/mus/window_port_mus.h (right):

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus...
ui/aura/mus/window_port_mus.h:254: // Used when this window is embedding a
client. Contains the client's content.
Could you isolate all the state related to embedding in its own class? That way
it's clear what is related to embedding as well as when there is an embedding.

[mfomitchev, 2016-12-23 00:03:49]

https://codereview.chromium.org/2580063002/diff/1/services/ui/ws/server_windo...
File services/ui/ws/server_window_compositor_frame_sink_manager.cc (right):

https://codereview.chromium.org/2580063002/diff/1/services/ui/ws/server_windo...
services/ui/ws/server_window_compositor_frame_sink_manager.cc:31:
waiting_for_initial_frames_ = !IsCompositorFrameSinkReadyAndNonEmpty(
On 2016/12/16 21:50:29, sky (OOO) wrote:
> Can we replace waiting_for_initial_frames_ with
> IsCompositorFrameSinkReadyAndNonEmpty(DEFAULT)?

Actually, it seems like currently this is always false (with or without my CL),
because it is initialized to false unless ui::mojom::kWaitForUnderlay_Property
is set, and that is never set. I've added a TODO to  clean this up. We could in
theory delete a bunch of code here. Will confirm with fsamuel and do it in a
separate CL if that's okay.

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus.cc
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus...
ui/aura/mus/window_port_mus.cc:211: void
WindowPortMus::UpdateSurfaceLayer(SurfaceInfo* surface_info) {
On 2016/12/16 21:50:29, sky (OOO) wrote:
> const SurfaceInfo?

Made it const reference.

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus...
ui/aura/mus/window_port_mus.cc:212: if (!surface_info)
On 2016/12/16 21:50:29, sky (OOO) wrote:
> When and why would null be passed in?

It is called with null from WindowPortMus's destructor. I suppose we could also
do it when the surface is destroyed in low memory situations. I changed the
logic so that we handle null in SetSurfaceIdFromServer, and UpdateSurfaceLayer
is always called with non-null surface_info.

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus.h
File ui/aura/mus/window_port_mus.h (right):

https://codereview.chromium.org/2580063002/diff/1/ui/aura/mus/window_port_mus...
ui/aura/mus/window_port_mus.h:254: // Used when this window is embedding a
client. Contains the client's content.
On 2016/12/16 21:50:29, sky (OOO) wrote:
> Could you isolate all the state related to embedding in its own class? That
way
> it's clear what is related to embedding as well as when there is an embedding.

Done.

[sky, 2017-01-03 21:53:08]

https://codereview.chromium.org/2580063002/diff/60001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2580063002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:57: // Used by WindowPortMus when it is embedding
a client. Responsible for setting
Can you move this into it's own .h/.cc?

https://codereview.chromium.org/2580063002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:62: EmbeddedContent(Window* window);
explicit

https://codereview.chromium.org/2580063002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:63: virtual ~EmbeddedContent();
Do you really need virtual?

[mfomitchev, 2017-01-03 22:28:50]

https://codereview.chromium.org/2580063002/diff/60001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2580063002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:57: // Used by WindowPortMus when it is embedding
a client. Responsible for setting
On 2017/01/03 21:53:07, sky (OOO) wrote:
> Can you move this into it's own .h/.cc?

Done.

https://codereview.chromium.org/2580063002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:62: EmbeddedContent(Window* window);
On 2017/01/03 21:53:07, sky (OOO) wrote:
> explicit

Done.

https://codereview.chromium.org/2580063002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:63: virtual ~EmbeddedContent();
On 2017/01/03 21:53:07, sky (OOO) wrote:
> Do you really need virtual?

Nope. Removed, thanks.

[mfomitchev, 2017-01-03 22:42:56]

The CQ bit was checked by mfomitchev@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-03 22:43:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-03 23:00:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-03 23:00:41]

Dry run: Try jobs failed on following builders:
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[sky, 2017-01-03 23:25:05]

https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
File ui/aura/mus/client_surface_embedder.cc (right):

https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
ui/aura/mus/client_surface_embedder.cc:73:
window_->layer()->Remove(clip_layer_.get());
I believe the destruction order is:

~Window
   DestroyLayer();
   delete WindowPortMus;

This means this code will try to access the layer after it's been destroyed.

[mfomitchev, 2017-01-03 23:41:12]

https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
File ui/aura/mus/client_surface_embedder.cc (right):

https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
ui/aura/mus/client_surface_embedder.cc:73:
window_->layer()->Remove(clip_layer_.get());
On 2017/01/03 23:25:05, sky (OOO) wrote:
> I believe the destruction order is:
> 
> ~Window
>    DestroyLayer();
>    delete WindowPortMus;
> 
> This means this code will try to access the layer after it's been destroyed.

Would it be okay to do port_owner_.reset() before calling DestroyLayer() in
Window~?

Alternatively, we can make it so we never destroy ClientSurfaceEmbedder from
WindowPortMus::SetSurfaceIdFromServer() once it is created. Since we currently
only call SetSurfaceIdFromServer() with nullptr from WindowPortMus's destructor,
perhaps we can just ignore null surface_info for the purposes of
ClientSurfaceEmbedder for now?

[sky, 2017-01-04 00:17:16]

On Tue, Jan 3, 2017 at 3:41 PM,  <mfomitchev@chromium.org> wrote:
>
>
https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
> File ui/aura/mus/client_surface_embedder.cc (right):
>
>
https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
> ui/aura/mus/client_surface_embedder.cc:73:
> window_->layer()->Remove(clip_layer_.get());
> On 2017/01/03 23:25:05, sky (OOO) wrote:
>> I believe the destruction order is:
>>
>> ~Window
>> DestroyLayer();
>> delete WindowPortMus;
>>
>> This means this code will try to access the layer after it's been
> destroyed.
>
> Would it be okay to do port_owner_.reset() before calling DestroyLayer()
> in Window~?

If that'll work, go for it.

>
> Alternatively, we can make it so we never destroy ClientSurfaceEmbedder
> from WindowPortMus::SetSurfaceIdFromServer() once it is created. Since
> we currently only call SetSurfaceIdFromServer() with nullptr from
> WindowPortMus's destructor, perhaps we can just ignore null surface_info
> for the purposes of ClientSurfaceEmbedder for now?

Might we want to destroy the ClientSurfaceEmbedder if we unembed or
the embedded client is destroyed?

Another option is to add a function to WindowPort that is called
before the layer is destroyed. This seems the least risky as there is
less risk of ~Layer ending up poking at something in Window that calls
through to WindowPort.

  -Scott

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Fady Samuel, 2017-01-04 12:34:17]

fsamuel@chromium.org changed reviewers:
+ fsamuel@chromium.org

[Fady Samuel, 2017-01-04 12:34:18]

https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
File ui/aura/mus/client_surface_embedder.cc (right):

https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
ui/aura/mus/client_surface_embedder.cc:89: cc::SurfaceInfo
cc_surface_info(surface_info.surface_id,
This should be fixed now. Please rebase.

[mfomitchev, 2017-01-04 20:13:48]

On 2017/01/04 00:17:16, sky wrote:
> On Tue, Jan 3, 2017 at 3:41 PM,  <mailto:mfomitchev@chromium.org> wrote:
> >
> >
>
https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
> > File ui/aura/mus/client_surface_embedder.cc (right):
> >
> >
>
https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
> > ui/aura/mus/client_surface_embedder.cc:73:
> > window_->layer()->Remove(clip_layer_.get());
> > On 2017/01/03 23:25:05, sky (OOO) wrote:
> >> I believe the destruction order is:
> >>
> >> ~Window
> >> DestroyLayer();
> >> delete WindowPortMus;
> >>
> >> This means this code will try to access the layer after it's been
> > destroyed.
> >
> > Would it be okay to do port_owner_.reset() before calling DestroyLayer()
> > in Window~?
> 
> If that'll work, go for it.
> 
> >
> > Alternatively, we can make it so we never destroy ClientSurfaceEmbedder
> > from WindowPortMus::SetSurfaceIdFromServer() once it is created. Since
> > we currently only call SetSurfaceIdFromServer() with nullptr from
> > WindowPortMus's destructor, perhaps we can just ignore null surface_info
> > for the purposes of ClientSurfaceEmbedder for now?
> 
> Might we want to destroy the ClientSurfaceEmbedder if we unembed or
> the embedded client is destroyed?
> 
> Another option is to add a function to WindowPort that is called
> before the layer is destroyed. This seems the least risky as there is
> less risk of ~Layer ending up poking at something in Window that calls
> through to WindowPort.
> 
>   -Scott
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.
> 

Sadrul pointed out to me that Layer's destructor already removes the layer from
its parent. So since clip_layer_ gets destroyed when ClientSurfaceEmbedder, we
don't have to worry about removing it from window's layer in
~ClientSurfaceEmbedder at all. I am going to update the CL.

[mfomitchev, 2017-01-04 20:22:33]

The CQ bit was checked by mfomitchev@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-04 20:23:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mfomitchev, 2017-01-04 20:45:31]

sky@, can you please take another look?

https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
File ui/aura/mus/client_surface_embedder.cc (right):

https://codereview.chromium.org/2580063002/diff/80001/ui/aura/mus/client_surf...
ui/aura/mus/client_surface_embedder.cc:89: cc::SurfaceInfo
cc_surface_info(surface_info.surface_id,
On 2017/01/04 12:34:18, Fady Samuel wrote:
> This should be fixed now. Please rebase.

Done.

[sky, 2017-01-04 21:04:02]

LGTM

[mfomitchev, 2017-01-04 21:12:50]

The CQ bit was checked by mfomitchev@chromium.org

[commit-bot: I haz the power, 2017-01-04 21:13:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-04 21:20:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-04 21:20:24]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[mfomitchev, 2017-01-04 21:22:20]

mfomitchev@chromium.org changed reviewers:
+ jbauman@chromium.org

[mfomitchev, 2017-01-04 21:22:20]

+jbauman@chromium.org for the DEPS change:
+cc/surfaces/surface_reference_factory.h

[jbauman, 2017-01-04 22:23:50]

DEPS change lgtm

[mfomitchev, 2017-01-04 22:25:02]

The CQ bit was checked by mfomitchev@chromium.org

[commit-bot: I haz the power, 2017-01-04 22:25:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-04 22:30:47]

CQ is committing da patch.

Bot data: {"patchset_id": 100001, "attempt_start_ts": 1483568702383030,
"parent_rev": "f3a2fc2fc9c9f16277a569212a91fb234d3a7eab", "commit_rev":
"13d8e83711fad8897d1ed5318a89e33410f75f7a"}

[commit-bot: I haz the power, 2017-01-04 22:31:19]

Description was changed from

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964
==========

to

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964

Review-Url: https://codereview.chromium.org/2580063002
==========

[commit-bot: I haz the power, 2017-01-04 22:31:21]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2017-01-04 22:32:46]

Description was changed from

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964

Review-Url: https://codereview.chromium.org/2580063002
==========

to

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964

Committed: https://crrev.com/a86d0169243b98b51554dcdbad647a24ea782aeb
Cr-Commit-Position: refs/heads/master@{#441492}
==========

[commit-bot: I haz the power, 2017-01-04 22:32:47]

Patchset 6 (id:??) landed as
https://crrev.com/a86d0169243b98b51554dcdbad647a24ea782aeb
Cr-Commit-Position: refs/heads/master@{#441492}

[Devlin, 2017-01-05 00:02:56]

A revert of this CL (patchset #6 id:100001) has been created in
https://codereview.chromium.org/2617603002/ by rdevlin.cronin@chromium.org.

The reason for reverting is: This appears to have broken mus ws unittests:
https://uberchromegw.corp.google.com/i/chromium.win/builders/Win%207%20Tests%...

It's the only mus-related change in the list.  Speculatively reverting..

[sadrul, 2017-01-05 19:32:56]

Description was changed from

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964

Committed: https://crrev.com/a86d0169243b98b51554dcdbad647a24ea782aeb
Cr-Commit-Position: refs/heads/master@{#441492}
==========

to

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964
CONTRIBUTOR=sadrul@chromium.org

Committed: https://crrev.com/a86d0169243b98b51554dcdbad647a24ea782aeb
Cr-Commit-Position: refs/heads/master@{#441492}
==========

[sadrul, 2017-01-05 19:39:55]

Description was changed from

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964
CONTRIBUTOR=sadrul@chromium.org

Committed: https://crrev.com/a86d0169243b98b51554dcdbad647a24ea782aeb
Cr-Commit-Position: refs/heads/master@{#441492}
==========

to

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964
CONTRIBUTOR=sadrul

Committed: https://crrev.com/a86d0169243b98b51554dcdbad647a24ea782aeb
Cr-Commit-Position: refs/heads/master@{#441492}
==========

[sadrul, 2017-01-05 19:42:03]

Description was changed from

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964
CONTRIBUTOR=sadrul

Committed: https://crrev.com/a86d0169243b98b51554dcdbad647a24ea782aeb
Cr-Commit-Position: refs/heads/master@{#441492}
==========

to

==========
Mustash: Ensure surfaces submitted to Mus by WM and embedders contain Surfaces
with embeded content.

- Use SurfaceLayers in embedders and Window Manager to properly position the
  embedded content in the layer tree.

- WM no longer uses underlay surfaces for window decorations. Instead they are
  submitted to Mus as part of the WM's surface.

- FrameGenerator now only creates SurfaceDrawQuad for the top-level window
  rather than recursively creating SurfaceDrawQuad for all windows in the
  window tree, since all surfaces are now part of the tree rooted at the
  surface of the top-level window.

BUG=672943,669964

Committed: https://crrev.com/a86d0169243b98b51554dcdbad647a24ea782aeb
Cr-Commit-Position: refs/heads/master@{#441492}
==========

[sadrul, 2017-01-05 19:53:28]

sadrul@chromium.org changed reviewers:
+ sadrul@chromium.org

[sadrul, 2017-01-05 19:53:29]

FYI: I have updated this CL with a fix in
https://codereview.chromium.org/2613903003/ (I tried to submit new patchsets in
this CL (I even tried adding CONTRIBUTOR in the CL description), but it doesn't
seem to work anymore)