Remove DCHECKs in SurfaceManager::RegisterFrameSinkHierarchy

Remove DCHECKs in SurfaceManager::RegisterFrameSinkHierarchy

SurfaceManager::RegisterFrameSinkHierarchy needs a valid parent and child
FrameSinkId. In other words, a hierarchy cannot be established until the parent
and child have SurfaceFactories. This isn't strictly a necessary requirement.

In Mus+Ash, all ServerWindows have a unique FrameSinkId, but not all
ServerWindows have corresponding CompositorFrames. If we only registered
BeginFrame hierarchies based on valid FrameSinkIds from the perspective of
SurfaceManager, then we'd have to know a priori which Windows will submit
CompositorFrames and WAIT for them to create CompositorFrameSinks which
complicates Mus-Gpu restartability somewhat.

Speaking to Enne, it sounds like we can simply drop these DCHECKs, they're
nice-to-haves but not strictly necessary. This also makes reparenting windows
MUCH MUCH easier in the window server as we don't need to worry about having to
update BeginFrame hierarchies to correspond to the nearest Surface based
ancestor on reparenting.

In a subsequent CL, AddChildFrame and RemoveChildFrameSink will move off
MojoCompositorFrameSinkPrivate onto DisplayCompositor.

BUG=653895
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2714553005
Cr-Commit-Position: refs/heads/master@{#452596}
Committed: https://chromium.googlesource.com/chromium/src/+/974e4a0d982d7502fe46f0db7621b390b38e1efc

[Fady Samuel, 2017-02-23 18:41:25]

Description was changed from

==========
Remove DCHECKs in SurfaceManager::RegisterFrameSinkHierarchy

SurfaceManager::RegisterFrameSinkHierarchy needs a valid parent and child
FrameSinkId. In other words, a hierarchy cannot be established until the parent
and child have SurfaceFactories. This isn't strictly a necessary requirement.

In Mus+Ash, all ServerWindows have a unique FrameSinkId, but not all
ServerWindows have corresponding CompositorFrames. If we only registered
BeginFrame hierarchies based on valid FrameSinkIds from the perspective of
SurfaceManager, then we'd have to know a priori which Windows will submit
CompositorFrames and WAIT for them to create CompositorFrameSinks which
complicates Mus-Gpu restartability somewhat.

Speaking to Enne, it sounds like we can simply drop these DCHECKs, they're
nice-to-haves but not strictly necessary. This also makes reparenting windows
MUCH MUCH easier in the window server as we don't need to worry about having to
update BeginFrame hierarchies to correspond to the nearest Surface based
ancestor on reparenting.

In a subsequent CL, AddChildFrame and RemoveChildFrameSink will move off
MojoCompositorFrameSinkPrivate onto DisplayCompositor.

BUG=653895
==========

to

==========
Remove DCHECKs in SurfaceManager::RegisterFrameSinkHierarchy

SurfaceManager::RegisterFrameSinkHierarchy needs a valid parent and child
FrameSinkId. In other words, a hierarchy cannot be established until the parent
and child have SurfaceFactories. This isn't strictly a necessary requirement.

In Mus+Ash, all ServerWindows have a unique FrameSinkId, but not all
ServerWindows have corresponding CompositorFrames. If we only registered
BeginFrame hierarchies based on valid FrameSinkIds from the perspective of
SurfaceManager, then we'd have to know a priori which Windows will submit
CompositorFrames and WAIT for them to create CompositorFrameSinks which
complicates Mus-Gpu restartability somewhat.

Speaking to Enne, it sounds like we can simply drop these DCHECKs, they're
nice-to-haves but not strictly necessary. This also makes reparenting windows
MUCH MUCH easier in the window server as we don't need to worry about having to
update BeginFrame hierarchies to correspond to the nearest Surface based
ancestor on reparenting.

In a subsequent CL, AddChildFrame and RemoveChildFrameSink will move off
MojoCompositorFrameSinkPrivate onto DisplayCompositor.

BUG=653895
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

[Fady Samuel, 2017-02-23 18:43:37]

fsamuel@chromium.org changed reviewers:
+ enne@chromium.org, penghuang@chromium.org

[Peng, 2017-02-23 18:47:51]

On 2017/02/23 18:43:37, Fady Samuel wrote:

Removing those DCHECKs fixes my issue. LGTN

[Peng, 2017-02-23 18:49:32]

On 2017/02/23 18:47:51, Peng wrote:
> On 2017/02/23 18:43:37, Fady Samuel wrote:
> 
> Removing those DCHECKs fixes my issue. LGTN

LGTM. :)

[enne (OOO), 2017-02-23 18:50:39]

lgtm

[Fady Samuel, 2017-02-23 18:51:29]

The CQ bit was checked by fsamuel@chromium.org

[commit-bot: I haz the power, 2017-02-23 18:51:56]

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-02-23 19:58:26]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1487875889042860, "parent_rev":
"b6c06ef04f90d35dcbdd08c083befa94152c1320", "commit_rev":
"974e4a0d982d7502fe46f0db7621b390b38e1efc"}

[commit-bot: I haz the power, 2017-02-23 19:59:04]

Description was changed from

==========
Remove DCHECKs in SurfaceManager::RegisterFrameSinkHierarchy

SurfaceManager::RegisterFrameSinkHierarchy needs a valid parent and child
FrameSinkId. In other words, a hierarchy cannot be established until the parent
and child have SurfaceFactories. This isn't strictly a necessary requirement.

In Mus+Ash, all ServerWindows have a unique FrameSinkId, but not all
ServerWindows have corresponding CompositorFrames. If we only registered
BeginFrame hierarchies based on valid FrameSinkIds from the perspective of
SurfaceManager, then we'd have to know a priori which Windows will submit
CompositorFrames and WAIT for them to create CompositorFrameSinks which
complicates Mus-Gpu restartability somewhat.

Speaking to Enne, it sounds like we can simply drop these DCHECKs, they're
nice-to-haves but not strictly necessary. This also makes reparenting windows
MUCH MUCH easier in the window server as we don't need to worry about having to
update BeginFrame hierarchies to correspond to the nearest Surface based
ancestor on reparenting.

In a subsequent CL, AddChildFrame and RemoveChildFrameSink will move off
MojoCompositorFrameSinkPrivate onto DisplayCompositor.

BUG=653895
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
==========

to

==========
Remove DCHECKs in SurfaceManager::RegisterFrameSinkHierarchy

SurfaceManager::RegisterFrameSinkHierarchy needs a valid parent and child
FrameSinkId. In other words, a hierarchy cannot be established until the parent
and child have SurfaceFactories. This isn't strictly a necessary requirement.

In Mus+Ash, all ServerWindows have a unique FrameSinkId, but not all
ServerWindows have corresponding CompositorFrames. If we only registered
BeginFrame hierarchies based on valid FrameSinkIds from the perspective of
SurfaceManager, then we'd have to know a priori which Windows will submit
CompositorFrames and WAIT for them to create CompositorFrameSinks which
complicates Mus-Gpu restartability somewhat.

Speaking to Enne, it sounds like we can simply drop these DCHECKs, they're
nice-to-haves but not strictly necessary. This also makes reparenting windows
MUCH MUCH easier in the window server as we don't need to worry about having to
update BeginFrame hierarchies to correspond to the nearest Surface based
ancestor on reparenting.

In a subsequent CL, AddChildFrame and RemoveChildFrameSink will move off
MojoCompositorFrameSinkPrivate onto DisplayCompositor.

BUG=653895
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Review-Url: https://codereview.chromium.org/2714553005
Cr-Commit-Position: refs/heads/master@{#452596}
Committed:
https://chromium.googlesource.com/chromium/src/+/974e4a0d982d7502fe46f0db7621...
==========

[commit-bot: I haz the power, 2017-02-23 19:59:05]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/974e4a0d982d7502fe46f0db7621...