Mus+Ash: propagate Surface ID to parents

Mus+Ash: propagate Surface ID to parents

Currently, in Mus+Ash, the window server is responsible for positioning
windows and generating SurfaceDrawQuads for them. This CL propagates surface
IDs for child windows to their parents so that parents can embed them directly
via CompositorFrames. This will happen in a subsequent patch.

A SurfaceSequence is allocated for the surface ID that is propagated up the
window hierarchy. As long as the parent holds on to the SurfaceSequence,
then the surface ID will be preserved. Once the parent is informed of a
new surface ID then it will return the SurfaceSequence back to the window
server for reclamation (mus-gpu in the future). If a window is destroyed then
it will also return its SurfaceSequence.

BUG=647852
Committed: https://crrev.com/065bde79d4e511f613ae89a2fc535029dae26100
Committed: https://crrev.com/433690106161ad7467d59901c469762f160fa4a2
Cr-Original-Commit-Position: refs/heads/master@{#425556}
Cr-Commit-Position: refs/heads/master@{#425566}

[Fady Samuel, 2016-10-12 18:10:59]

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

[Fady Samuel, 2016-10-12 18:11:00]

Hi Sadrul,

I haven't written tests yet. Please let me know if this API works for you. 

Thanks,

Fady

[Fady Samuel, 2016-10-12 18:13:39]

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

[commit-bot: I haz the power, 2016-10-12 18:14:01]

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

[rjkroege, 2016-10-12 18:21:16]

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

[rjkroege, 2016-10-12 18:21:17]

https://codereview.chromium.org/2414683003/diff/20001/services/ui/public/inte...
File services/ui/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/2414683003/diff/20001/services/ui/public/inte...
services/ui/public/interfaces/window_tree.mojom:428: // Invoked when a client
window submits a new surface ID.
per our discussion: in the long term, the client should give the surface id
directly to the embedder yes? So this is temporary yes?

[Fady Samuel, 2016-10-12 18:22:57]

https://codereview.chromium.org/2414683003/diff/20001/services/ui/public/inte...
File services/ui/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/2414683003/diff/20001/services/ui/public/inte...
services/ui/public/interfaces/window_tree.mojom:428: // Invoked when a client
window submits a new surface ID.
On 2016/10/12 18:21:16, rjkroege wrote:
> per our discussion: in the long term, the client should give the surface id
> directly to the embedder yes? So this is temporary yes?

Yes, until we figure out all the details of a direct connection.

[rjkroege, 2016-10-12 18:28:15]

On 2016/10/12 18:22:57, Fady Samuel wrote:
>
https://codereview.chromium.org/2414683003/diff/20001/services/ui/public/inte...
> File services/ui/public/interfaces/window_tree.mojom (right):
> 
>
https://codereview.chromium.org/2414683003/diff/20001/services/ui/public/inte...
> services/ui/public/interfaces/window_tree.mojom:428: // Invoked when a client
> window submits a new surface ID.
> On 2016/10/12 18:21:16, rjkroege wrote:
> > per our discussion: in the long term, the client should give the surface id
> > directly to the embedder yes? So this is temporary yes?
> 
> Yes, until we figure out all the details of a direct connection.

excellent. you should add appropriate TODOs please?

[sadrul, 2016-10-13 04:26:21]

https://codereview.chromium.org/2414683003/diff/40001/services/ui/public/cpp/...
File services/ui/public/cpp/window.cc (right):

https://codereview.chromium.org/2414683003/diff/40001/services/ui/public/cpp/...
services/ui/public/cpp/window.cc:815: // SurfaceSequence and returning the
refernece.
Each ui::Window could have some explicit SurfaceSequenceHandler that gets
notified here instead (e.g. there's a ui::Window::InputEventHandler for handling
input events).

[Fady Samuel, 2016-10-13 18:01:21]

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

[Fady Samuel, 2016-10-14 17:41:09]

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

[Fady Samuel, 2016-10-14 17:41:19]

PTAL Sadrul!

[commit-bot: I haz the power, 2016-10-14 17:41:31]

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

[Fady Samuel, 2016-10-14 17:42:40]

https://codereview.chromium.org/2414683003/diff/40001/services/ui/public/cpp/...
File services/ui/public/cpp/window.cc (right):

https://codereview.chromium.org/2414683003/diff/40001/services/ui/public/cpp/...
services/ui/public/cpp/window.cc:815: // SurfaceSequence and returning the
refernece.
On 2016/10/13 04:26:21, sadrul wrote:
> Each ui::Window could have some explicit SurfaceSequenceHandler that gets
> notified here instead (e.g. there's a ui::Window::InputEventHandler for
handling
> input events).

Done.

[rjkroege, 2016-10-14 19:19:41]

On 2016/10/14 17:42:40, Fady Samuel wrote:
>
https://codereview.chromium.org/2414683003/diff/40001/services/ui/public/cpp/...
> File services/ui/public/cpp/window.cc (right):
> 
>
https://codereview.chromium.org/2414683003/diff/40001/services/ui/public/cpp/...
> services/ui/public/cpp/window.cc:815: // SurfaceSequence and returning the
> refernece.
> On 2016/10/13 04:26:21, sadrul wrote:
> > Each ui::Window could have some explicit SurfaceSequenceHandler that gets
> > notified here instead (e.g. there's a ui::Window::InputEventHandler for
> handling
> > input events).
> 
> Done.

lgtm

[Fady Samuel, 2016-10-14 19:21:31]

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

[Fady Samuel, 2016-10-14 19:21:32]

+sky@ for a services/ui stamp (I'll wait for sadrul too).

Testing is coming too but I want to do it in another patch to unblock Sadrul and
Mikhail sooner rather than later.

[Fady Samuel, 2016-10-14 19:21:44]

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

[commit-bot: I haz the power, 2016-10-14 19:22:20]

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

[sky, 2016-10-14 20:55:46]

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/cpp...
File services/ui/public/cpp/window.h (right):

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/cpp...
services/ui/public/cpp/window.h:406: struct SurfaceInfo {
I think this code would be clearer if you passed around the SurfaceInfo struct
rather than members. Specifically:

SurfaceIdHandler::OnChildWindowSurfaceCreated() would take a
std::unique_ptr<SurfaceInfo>* . If the function takes ownership it uses
std::move. That way no return value and expectations are a bit clearer.

LocalSetSurfaceId in Window becomes
LocalSetSurface(std::unique_ptr<SurfaceInfo>). That way you can call it with
null and it's easier to understand what's going on. Additionally the member
becomes std::unique_ptr<SurfaceInfo> so that you know what null means.

the struct were moved to SurfaceIdHandler and OnChildWindowSurfaceCreated took a
std::unique_ptr<SurfaceIdHandler>*. That way LocalSetSurface

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/int...
File services/ui/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/int...
services/ui/public/interfaces/window_tree.mojom:147:
ReturnSurfaceReference(uint32 window_id, cc.mojom.SurfaceSequence sequence);
Can this name be more explicit, maybe something like OnWindowSurfaceDetached or
something, or OnWindowSurfaceNoLongerUsed? Or maye DestroyWindowSurface?

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/int...
services/ui/public/interfaces/window_tree.mojom:428: // Invoked when a client
window submits a new surface ID.
Please better indicate what the client is expected to do here.

https://codereview.chromium.org/2414683003/diff/100001/services/ui/ws/window_...
File services/ui/ws/window_server.cc (right):

https://codereview.chromium.org/2414683003/diff/100001/services/ui/ws/window_...
services/ui/ws/window_server.cc:818:
pair.second->ProcessWindowSurfaceCreated(window, surface_id, frame_size,
Only the owner of window->parent() cares about this, right? I think you should
send it only to that connection here.

[commit-bot: I haz the power, 2016-10-14 21:30:47]

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

[commit-bot: I haz the power, 2016-10-14 21:30:48]

Dry run: This issue passed the CQ dry run.

[Fady Samuel, 2016-10-14 21:32:48]

PTAL Scott! I've addressed your comments and added a unit test.

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/cpp...
File services/ui/public/cpp/window.h (right):

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/cpp...
services/ui/public/cpp/window.h:406: struct SurfaceInfo {
On 2016/10/14 20:55:46, sky wrote:
> I think this code would be clearer if you passed around the SurfaceInfo struct
> rather than members. Specifically:
> 
> SurfaceIdHandler::OnChildWindowSurfaceCreated() would take a
> std::unique_ptr<SurfaceInfo>* . If the function takes ownership it uses
> std::move. That way no return value and expectations are a bit clearer.
> 
> LocalSetSurfaceId in Window becomes
> LocalSetSurface(std::unique_ptr<SurfaceInfo>). That way you can call it with
> null and it's easier to understand what's going on. Additionally the member
> becomes std::unique_ptr<SurfaceInfo> so that you know what null means.
> 
> the struct were moved to SurfaceIdHandler and OnChildWindowSurfaceCreated took
a
> std::unique_ptr<SurfaceIdHandler>*. That way LocalSetSurface

Done.

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/int...
File services/ui/public/interfaces/window_tree.mojom (right):

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/int...
services/ui/public/interfaces/window_tree.mojom:147:
ReturnSurfaceReference(uint32 window_id, cc.mojom.SurfaceSequence sequence);
On 2016/10/14 20:55:46, sky wrote:
> Can this name be more explicit, maybe something like OnWindowSurfaceDetached
or
> something, or OnWindowSurfaceNoLongerUsed? Or maye DestroyWindowSurface?

None of these are good names though because there may be multiple references to
a single surface ID (for thumbnailing or something). This returns just one
reference.

https://codereview.chromium.org/2414683003/diff/100001/services/ui/public/int...
services/ui/public/interfaces/window_tree.mojom:428: // Invoked when a client
window submits a new surface ID.
On 2016/10/14 20:55:46, sky wrote:
> Please better indicate what the client is expected to do here.

Done.

https://codereview.chromium.org/2414683003/diff/100001/services/ui/ws/window_...
File services/ui/ws/window_server.cc (right):

https://codereview.chromium.org/2414683003/diff/100001/services/ui/ws/window_...
services/ui/ws/window_server.cc:818:
pair.second->ProcessWindowSurfaceCreated(window, surface_id, frame_size,
On 2016/10/14 20:55:46, sky wrote:
> Only the owner of window->parent() cares about this, right? I think you should
> send it only to that connection here.

Done.

[Fady Samuel, 2016-10-14 21:36:42]

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

[Fady Samuel, 2016-10-14 21:36:43]

+tsepez@ for mojom

[Tom Sepez, 2016-10-14 21:49:13]

lgtm

[sky, 2016-10-14 21:55:34]

https://codereview.chromium.org/2414683003/diff/140001/services/ui/public/cpp...
File services/ui/public/cpp/surface_id_handler.h (right):

https://codereview.chromium.org/2414683003/diff/140001/services/ui/public/cpp...
services/ui/public/cpp/surface_id_handler.h:15: virtual void
OnChildWindowSurfaceCreated(
This may be called with null, right? In which case created is confusing. Created
also implies a one time thing. How about OnChildWindowSurfaceChanged(). And make
it clear this may be called with null.

https://codereview.chromium.org/2414683003/diff/140001/services/ui/public/cpp...
services/ui/public/cpp/surface_id_handler.h:17:
std::unique_ptr<Window::SurfaceInfo>* surface_info) = 0;
You'll need to include window.h here (which seems bad). Maybe move into it's own
header, or define it here (as a toplevel class, not in inner class).

https://codereview.chromium.org/2414683003/diff/140001/services/ui/ws/window_...
File services/ui/ws/window_server.cc (right):

https://codereview.chromium.org/2414683003/diff/140001/services/ui/ws/window_...
services/ui/ws/window_server.cc:818:
pair.second->ProcessWindowSurfaceCreated(window, surface_id, frame_size,
It doesn't seem like you updated this based on my last review:
"Only the owner of window->parent() cares about this, right? I think you should
send it only to that connection here."
I'm saying you should lookup the WindowTree based on the owner parent id and not
loop through all.

[Fady Samuel, 2016-10-14 22:20:14]

PTAL sky@

https://codereview.chromium.org/2414683003/diff/140001/services/ui/public/cpp...
File services/ui/public/cpp/surface_id_handler.h (right):

https://codereview.chromium.org/2414683003/diff/140001/services/ui/public/cpp...
services/ui/public/cpp/surface_id_handler.h:15: virtual void
OnChildWindowSurfaceCreated(
On 2016/10/14 21:55:34, sky wrote:
> This may be called with null, right? In which case created is confusing.
Created
> also implies a one time thing. How about OnChildWindowSurfaceChanged(). And
make
> it clear this may be called with null.

Done.

https://codereview.chromium.org/2414683003/diff/140001/services/ui/public/cpp...
services/ui/public/cpp/surface_id_handler.h:17:
std::unique_ptr<Window::SurfaceInfo>* surface_info) = 0;
On 2016/10/14 21:55:34, sky wrote:
> You'll need to include window.h here (which seems bad). Maybe move into it's
own
> header, or define it here (as a toplevel class, not in inner class).

Done.

https://codereview.chromium.org/2414683003/diff/140001/services/ui/ws/window_...
File services/ui/ws/window_server.cc (right):

https://codereview.chromium.org/2414683003/diff/140001/services/ui/ws/window_...
services/ui/ws/window_server.cc:818:
pair.second->ProcessWindowSurfaceCreated(window, surface_id, frame_size,
On 2016/10/14 21:55:34, sky wrote:
> It doesn't seem like you updated this based on my last review:
> "Only the owner of window->parent() cares about this, right? I think you
should
> send it only to that connection here."
> I'm saying you should lookup the WindowTree based on the owner parent id and
not
> loop through all.

Done. I made the change inside ProcessWindowSurfaceCreated. I missed the
GetTreeWithId method. Fixed.

[sky, 2016-10-14 22:44:36]

LGTM with the following changes.

https://codereview.chromium.org/2414683003/diff/180001/services/ui/public/cpp...
File services/ui/public/cpp/surface_id_handler.h (right):

https://codereview.chromium.org/2414683003/diff/180001/services/ui/public/cpp...
services/ui/public/cpp/surface_id_handler.h:16: struct SurfaceInfo {
Please add a description.

https://codereview.chromium.org/2414683003/diff/180001/services/ui/ws/window_...
File services/ui/ws/window_server.cc (right):

https://codereview.chromium.org/2414683003/diff/180001/services/ui/ws/window_...
services/ui/ws/window_server.cc:817:
GetTreeWithId(window->parent()->id().client_id)
Please make sure there is a WindowTree. I'm mildly worried about the WM trying
to submit a surface for it's root.

[Fady Samuel, 2016-10-14 23:09:50]

Thanks Scott! CQ'ing now.

https://codereview.chromium.org/2414683003/diff/180001/services/ui/public/cpp...
File services/ui/public/cpp/surface_id_handler.h (right):

https://codereview.chromium.org/2414683003/diff/180001/services/ui/public/cpp...
services/ui/public/cpp/surface_id_handler.h:16: struct SurfaceInfo {
On 2016/10/14 22:44:36, sky wrote:
> Please add a description.

Done.

https://codereview.chromium.org/2414683003/diff/180001/services/ui/ws/window_...
File services/ui/ws/window_server.cc (right):

https://codereview.chromium.org/2414683003/diff/180001/services/ui/ws/window_...
services/ui/ws/window_server.cc:817:
GetTreeWithId(window->parent()->id().client_id)
On 2016/10/14 22:44:36, sky wrote:
> Please make sure there is a WindowTree. I'm mildly worried about the WM trying
> to submit a surface for it's root.

Done.

[Fady Samuel, 2016-10-14 23:10:03]

The CQ bit was checked by fsamuel@chromium.org

[Fady Samuel, 2016-10-14 23:10:03]

The patchset sent to the CQ was uploaded after l-g-t-m from
rjkroege@chromium.org, tsepez@chromium.org, sky@chromium.org
Link to the patchset: https://codereview.chromium.org/2414683003/#ps200001
(title: "Addressed Scott's comments")

[commit-bot: I haz the power, 2016-10-14 23:10:23]

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-10-15 00:18:31]

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

[commit-bot: I haz the power, 2016-10-15 00:18:32]

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

[Fady Samuel, 2016-10-15 06:37:53]

The CQ bit was checked by fsamuel@chromium.org

[commit-bot: I haz the power, 2016-10-15 06:38:05]

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-10-15 07:28:27]

Committed patchset #11 (id:200001)

[commit-bot: I haz the power, 2016-10-15 07:30:38]

Description was changed from

==========
Mus+Ash: propagate Surface ID to parents

Currently, in Mus+Ash, the window server is responsible for positioning
windows and generating SurfaceDrawQuads for them. This CL propagates surface
IDs for child windows to their parents so that parents can embed them directly
via CompositorFrames. This will happen in a subsequent patch.

A SurfaceSequence is allocated for the surface ID that is propagated up the
window hierarchy. As long as the parent holds on to the SurfaceSequence,
then the surface ID will be preserved. Once the parent is informed of a
new surface ID then it will return the SurfaceSequence back to the window
server for reclamation (mus-gpu in the future). If a window is destroyed then
it will also return its SurfaceSequence.

BUG=647852
==========

to

==========
Mus+Ash: propagate Surface ID to parents

Currently, in Mus+Ash, the window server is responsible for positioning
windows and generating SurfaceDrawQuads for them. This CL propagates surface
IDs for child windows to their parents so that parents can embed them directly
via CompositorFrames. This will happen in a subsequent patch.

A SurfaceSequence is allocated for the surface ID that is propagated up the
window hierarchy. As long as the parent holds on to the SurfaceSequence,
then the surface ID will be preserved. Once the parent is informed of a
new surface ID then it will return the SurfaceSequence back to the window
server for reclamation (mus-gpu in the future). If a window is destroyed then
it will also return its SurfaceSequence.

BUG=647852

Committed: https://crrev.com/065bde79d4e511f613ae89a2fc535029dae26100
Cr-Commit-Position: refs/heads/master@{#425556}
==========

[commit-bot: I haz the power, 2016-10-15 07:30:39]

Patchset 11 (id:??) landed as
https://crrev.com/065bde79d4e511f613ae89a2fc535029dae26100
Cr-Commit-Position: refs/heads/master@{#425556}

[Ken Rockot(use gerrit already), 2016-10-15 15:40:19]

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

[Ken Rockot(use gerrit already), 2016-10-15 15:40:20]

Pretty sure this is causing tons of mash_browser_tests flake. Flake started when
this landed.

[Ken Rockot(use gerrit already), 2016-10-15 15:40:47]

A revert of this CL (patchset #11 id:200001) has been created in
https://codereview.chromium.org/2424633002/ by rockot@chromium.org.

The reason for reverting is: Speculative revert for mash_browser_tests flake.

[Fady Samuel, 2016-10-15 16:31:43]

I fixed the crash: we were following a null |surface_info| on
LocalSetSurfaceId(nullptr) to compare it to the existing
surface_info_->surface_id. I have added a null check to address this issue.
Relanding now.

[Fady Samuel, 2016-10-15 16:31:57]

Description was changed from

==========
Mus+Ash: propagate Surface ID to parents

Currently, in Mus+Ash, the window server is responsible for positioning
windows and generating SurfaceDrawQuads for them. This CL propagates surface
IDs for child windows to their parents so that parents can embed them directly
via CompositorFrames. This will happen in a subsequent patch.

A SurfaceSequence is allocated for the surface ID that is propagated up the
window hierarchy. As long as the parent holds on to the SurfaceSequence,
then the surface ID will be preserved. Once the parent is informed of a
new surface ID then it will return the SurfaceSequence back to the window
server for reclamation (mus-gpu in the future). If a window is destroyed then
it will also return its SurfaceSequence.

BUG=647852

Committed: https://crrev.com/065bde79d4e511f613ae89a2fc535029dae26100
Cr-Commit-Position: refs/heads/master@{#425556}
==========

to

==========
Mus+Ash: propagate Surface ID to parents

Currently, in Mus+Ash, the window server is responsible for positioning
windows and generating SurfaceDrawQuads for them. This CL propagates surface
IDs for child windows to their parents so that parents can embed them directly
via CompositorFrames. This will happen in a subsequent patch.

A SurfaceSequence is allocated for the surface ID that is propagated up the
window hierarchy. As long as the parent holds on to the SurfaceSequence,
then the surface ID will be preserved. Once the parent is informed of a
new surface ID then it will return the SurfaceSequence back to the window
server for reclamation (mus-gpu in the future). If a window is destroyed then
it will also return its SurfaceSequence.

BUG=647852

Committed: https://crrev.com/065bde79d4e511f613ae89a2fc535029dae26100
Cr-Commit-Position: refs/heads/master@{#425556}
==========

[Fady Samuel, 2016-10-15 16:32:04]

The CQ bit was checked by fsamuel@chromium.org

[Fady Samuel, 2016-10-15 16:32:05]

The patchset sent to the CQ was uploaded after l-g-t-m from
rjkroege@chromium.org, sky@chromium.org, tsepez@chromium.org
Link to the patchset: https://codereview.chromium.org/2414683003/#ps210001
(title: "Don't follow null surface_info")

[commit-bot: I haz the power, 2016-10-15 16:34:08]

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-10-15 17:28:46]

Description was changed from

==========
Mus+Ash: propagate Surface ID to parents

Currently, in Mus+Ash, the window server is responsible for positioning
windows and generating SurfaceDrawQuads for them. This CL propagates surface
IDs for child windows to their parents so that parents can embed them directly
via CompositorFrames. This will happen in a subsequent patch.

A SurfaceSequence is allocated for the surface ID that is propagated up the
window hierarchy. As long as the parent holds on to the SurfaceSequence,
then the surface ID will be preserved. Once the parent is informed of a
new surface ID then it will return the SurfaceSequence back to the window
server for reclamation (mus-gpu in the future). If a window is destroyed then
it will also return its SurfaceSequence.

BUG=647852

Committed: https://crrev.com/065bde79d4e511f613ae89a2fc535029dae26100
Cr-Commit-Position: refs/heads/master@{#425556}
==========

to

==========
Mus+Ash: propagate Surface ID to parents

Currently, in Mus+Ash, the window server is responsible for positioning
windows and generating SurfaceDrawQuads for them. This CL propagates surface
IDs for child windows to their parents so that parents can embed them directly
via CompositorFrames. This will happen in a subsequent patch.

A SurfaceSequence is allocated for the surface ID that is propagated up the
window hierarchy. As long as the parent holds on to the SurfaceSequence,
then the surface ID will be preserved. Once the parent is informed of a
new surface ID then it will return the SurfaceSequence back to the window
server for reclamation (mus-gpu in the future). If a window is destroyed then
it will also return its SurfaceSequence.

BUG=647852

Committed: https://crrev.com/065bde79d4e511f613ae89a2fc535029dae26100
Cr-Commit-Position: refs/heads/master@{#425556}
==========

[commit-bot: I haz the power, 2016-10-15 17:28:47]

Committed patchset #12 (id:210001)

[commit-bot: I haz the power, 2016-10-15 17:30:28]

Description was changed from

==========
Mus+Ash: propagate Surface ID to parents

Currently, in Mus+Ash, the window server is responsible for positioning
windows and generating SurfaceDrawQuads for them. This CL propagates surface
IDs for child windows to their parents so that parents can embed them directly
via CompositorFrames. This will happen in a subsequent patch.

A SurfaceSequence is allocated for the surface ID that is propagated up the
window hierarchy. As long as the parent holds on to the SurfaceSequence,
then the surface ID will be preserved. Once the parent is informed of a
new surface ID then it will return the SurfaceSequence back to the window
server for reclamation (mus-gpu in the future). If a window is destroyed then
it will also return its SurfaceSequence.

BUG=647852

Committed: https://crrev.com/065bde79d4e511f613ae89a2fc535029dae26100
Cr-Commit-Position: refs/heads/master@{#425556}
==========

to

==========
Mus+Ash: propagate Surface ID to parents

Currently, in Mus+Ash, the window server is responsible for positioning
windows and generating SurfaceDrawQuads for them. This CL propagates surface
IDs for child windows to their parents so that parents can embed them directly
via CompositorFrames. This will happen in a subsequent patch.

A SurfaceSequence is allocated for the surface ID that is propagated up the
window hierarchy. As long as the parent holds on to the SurfaceSequence,
then the surface ID will be preserved. Once the parent is informed of a
new surface ID then it will return the SurfaceSequence back to the window
server for reclamation (mus-gpu in the future). If a window is destroyed then
it will also return its SurfaceSequence.

BUG=647852

Committed: https://crrev.com/065bde79d4e511f613ae89a2fc535029dae26100
Committed: https://crrev.com/433690106161ad7467d59901c469762f160fa4a2
Cr-Original-Commit-Position: refs/heads/master@{#425556}
Cr-Commit-Position: refs/heads/master@{#425566}
==========

[commit-bot: I haz the power, 2016-10-15 17:30:29]

Patchset 12 (id:??) landed as
https://crrev.com/433690106161ad7467d59901c469762f160fa4a2
Cr-Commit-Position: refs/heads/master@{#425566}