Delete OnscreenDisplayClient and TopLevelDisplayClient.

Delete OnscreenDisplayClient and TopLevelDisplayClient.

These classes just own Display and forward along the client calls to
the owner of themselves. Instead, have code own a cc::Display directly.

Part of this reworks how OutputSurface gets to the Display. Previously
the OnscreenDisplayClient would hold the OutputSurface created during
creation of the delegated OutputSurface to be given to the compositor.
But it wouldn't be given to the Display until the compositor bound the
delegated OutputSurface from LayerTreeHostImpl.

Now, we give the display's OutputSurface to it at construction time of
the Display. The Display will continue to bind it when it is
Initialize()'d by the delegated output surface in the compositor being
bound. However, now the DisplayClient (the delegated OutputSurface) is
created after the Display is, since it wants to have a pointer to the
Display. So we give the DisplayClient to the Display at the time of
Initialize().

Lastly, SurfaceDisplayOutputSurface was doing some shady things to avoid
binding the lost context callback on the shared context provider (shared
between the compositor's delegated and the display's OutputSurface) more
that once. It would avoid calling OutputSurface::BindToClient() and
implemented it partially itself. I changed this to call the parent but
just unset the callback with a comment explaining that we want it to go
to the Display (via its own OutputSurface) first, so we have it set up
the callback (which happens in Initialize).

The point of this whole thing was to work on merging the two delegated-
to-a-display output surface implementations: SurfaceDisplayOutputSurface
and PixelTestDelegatingOutputSurface. In the end this doesn't appear
feasible since the PixelTestDelegatingOutputSurface is meant for the
renderer, which can have a threaded compositor. In that case, the
Display, SurfaceManager, etc should be created, used and destroyed on the
compositor thread since they are not threadsafe. At least hopefully this
makes ownership more clear.

R=enne@chromium.org, fsamuel@chromium.org, jbauman@chromium.org, sievers@chromium.org
BUG=487471
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/324faea6be5251efbffb7438876478500b5532cf
Cr-Commit-Position: refs/heads/master@{#399348}

[danakj, 2016-06-01 23:57:11]

Description was changed from

==========
Delete OnscreenDisplayClient and TopLevelDisplayClient.

These classes just own Display and forward along the client calls to
the owner of themselves. Instead, have code own a cc::Display directly.

Part of this reworks how OutputSurface gets to the Display. Previously
the OnscreenDisplayClient would hold the OutputSurface created during
creation of the delegated OutputSurface to be given to the compositor.
But it wouldn't be given to the Display until the compositor bound the
delegated OutputSurface from LayerTreeHostImpl.

Now, we give the display's OutputSurface to it at construction time of
the Display. The Display will continue to bind it when it is
Initialize()'d by the delegated output surface in the compositor being
bound. However, now the DisplayClient (the delegated OutputSurface) is
created after the Display is, since it wants to have a pointer to the
Display. So we give the DisplayClient to the Display at the time of
Initialize().

Lastly, SurfaceDisplayOutputSurface was doing some shady things to avoid
binding the lost context callback on the shared context provider (shared
between the compositor's delegated and the display's OutputSurface) more
that once. It would avoid calling OutputSurface::BindToClient() and
implemented it partially itself. I changed this to call the parent but
just unset the callback with a comment explaining that we want it to go
to the Display (via its own OutputSurface) first, so we have it set up
the callback (which happens in Initialize).

The point of this whole thing was to work on merging the two delegated-
to-a-display output surface implementations: SurfaceDisplayOutputSurface
and PixelTestDelegatingOutputSurface. In the end this doesn't appear
feasible since the PixelTestDelegatingOutputSurface is meant for the
renderer, which can have a threaded compositor. In that case, the
Display, SurfaceManager, etc should be created, used and destroyed on the
compositor thread since they are not threadsafe.

R=enne@chromium.org, fsamuel@chromium.org, jbauman@chromium.org,
sievers@chromium.org
BUG=487471
==========

to

==========
Delete OnscreenDisplayClient and TopLevelDisplayClient.

These classes just own Display and forward along the client calls to
the owner of themselves. Instead, have code own a cc::Display directly.

Part of this reworks how OutputSurface gets to the Display. Previously
the OnscreenDisplayClient would hold the OutputSurface created during
creation of the delegated OutputSurface to be given to the compositor.
But it wouldn't be given to the Display until the compositor bound the
delegated OutputSurface from LayerTreeHostImpl.

Now, we give the display's OutputSurface to it at construction time of
the Display. The Display will continue to bind it when it is
Initialize()'d by the delegated output surface in the compositor being
bound. However, now the DisplayClient (the delegated OutputSurface) is
created after the Display is, since it wants to have a pointer to the
Display. So we give the DisplayClient to the Display at the time of
Initialize().

Lastly, SurfaceDisplayOutputSurface was doing some shady things to avoid
binding the lost context callback on the shared context provider (shared
between the compositor's delegated and the display's OutputSurface) more
that once. It would avoid calling OutputSurface::BindToClient() and
implemented it partially itself. I changed this to call the parent but
just unset the callback with a comment explaining that we want it to go
to the Display (via its own OutputSurface) first, so we have it set up
the callback (which happens in Initialize).

The point of this whole thing was to work on merging the two delegated-
to-a-display output surface implementations: SurfaceDisplayOutputSurface
and PixelTestDelegatingOutputSurface. In the end this doesn't appear
feasible since the PixelTestDelegatingOutputSurface is meant for the
renderer, which can have a threaded compositor. In that case, the
Display, SurfaceManager, etc should be created, used and destroyed on the
compositor thread since they are not threadsafe.

R=enne@chromium.org, fsamuel@chromium.org, jbauman@chromium.org,
sievers@chromium.org
BUG=487471
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[danakj, 2016-06-01 23:57:24]

Description was changed from

==========
Delete OnscreenDisplayClient and TopLevelDisplayClient.

These classes just own Display and forward along the client calls to
the owner of themselves. Instead, have code own a cc::Display directly.

Part of this reworks how OutputSurface gets to the Display. Previously
the OnscreenDisplayClient would hold the OutputSurface created during
creation of the delegated OutputSurface to be given to the compositor.
But it wouldn't be given to the Display until the compositor bound the
delegated OutputSurface from LayerTreeHostImpl.

Now, we give the display's OutputSurface to it at construction time of
the Display. The Display will continue to bind it when it is
Initialize()'d by the delegated output surface in the compositor being
bound. However, now the DisplayClient (the delegated OutputSurface) is
created after the Display is, since it wants to have a pointer to the
Display. So we give the DisplayClient to the Display at the time of
Initialize().

Lastly, SurfaceDisplayOutputSurface was doing some shady things to avoid
binding the lost context callback on the shared context provider (shared
between the compositor's delegated and the display's OutputSurface) more
that once. It would avoid calling OutputSurface::BindToClient() and
implemented it partially itself. I changed this to call the parent but
just unset the callback with a comment explaining that we want it to go
to the Display (via its own OutputSurface) first, so we have it set up
the callback (which happens in Initialize).

The point of this whole thing was to work on merging the two delegated-
to-a-display output surface implementations: SurfaceDisplayOutputSurface
and PixelTestDelegatingOutputSurface. In the end this doesn't appear
feasible since the PixelTestDelegatingOutputSurface is meant for the
renderer, which can have a threaded compositor. In that case, the
Display, SurfaceManager, etc should be created, used and destroyed on the
compositor thread since they are not threadsafe.

R=enne@chromium.org, fsamuel@chromium.org, jbauman@chromium.org,
sievers@chromium.org
BUG=487471
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Delete OnscreenDisplayClient and TopLevelDisplayClient.

These classes just own Display and forward along the client calls to
the owner of themselves. Instead, have code own a cc::Display directly.

Part of this reworks how OutputSurface gets to the Display. Previously
the OnscreenDisplayClient would hold the OutputSurface created during
creation of the delegated OutputSurface to be given to the compositor.
But it wouldn't be given to the Display until the compositor bound the
delegated OutputSurface from LayerTreeHostImpl.

Now, we give the display's OutputSurface to it at construction time of
the Display. The Display will continue to bind it when it is
Initialize()'d by the delegated output surface in the compositor being
bound. However, now the DisplayClient (the delegated OutputSurface) is
created after the Display is, since it wants to have a pointer to the
Display. So we give the DisplayClient to the Display at the time of
Initialize().

Lastly, SurfaceDisplayOutputSurface was doing some shady things to avoid
binding the lost context callback on the shared context provider (shared
between the compositor's delegated and the display's OutputSurface) more
that once. It would avoid calling OutputSurface::BindToClient() and
implemented it partially itself. I changed this to call the parent but
just unset the callback with a comment explaining that we want it to go
to the Display (via its own OutputSurface) first, so we have it set up
the callback (which happens in Initialize).

The point of this whole thing was to work on merging the two delegated-
to-a-display output surface implementations: SurfaceDisplayOutputSurface
and PixelTestDelegatingOutputSurface. In the end this doesn't appear
feasible since the PixelTestDelegatingOutputSurface is meant for the
renderer, which can have a threaded compositor. In that case, the
Display, SurfaceManager, etc should be created, used and destroyed on the
compositor thread since they are not threadsafe. At least hopefully this
makes ownership more clear.

R=enne@chromium.org, fsamuel@chromium.org, jbauman@chromium.org,
sievers@chromium.org
BUG=487471
==========

[danakj, 2016-06-01 23:57:39]

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

[commit-bot: I haz the power, 2016-06-01 23:58:32]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2036563002/1

[commit-bot: I haz the power, 2016-06-02 00:12:35]

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

[commit-bot: I haz the power, 2016-06-02 00:12:36]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Fady Samuel, 2016-06-02 00:24:57]

mus lgtm

[danakj, 2016-06-02 00:35:39]

Description was changed from

==========
Delete OnscreenDisplayClient and TopLevelDisplayClient.

These classes just own Display and forward along the client calls to
the owner of themselves. Instead, have code own a cc::Display directly.

Part of this reworks how OutputSurface gets to the Display. Previously
the OnscreenDisplayClient would hold the OutputSurface created during
creation of the delegated OutputSurface to be given to the compositor.
But it wouldn't be given to the Display until the compositor bound the
delegated OutputSurface from LayerTreeHostImpl.

Now, we give the display's OutputSurface to it at construction time of
the Display. The Display will continue to bind it when it is
Initialize()'d by the delegated output surface in the compositor being
bound. However, now the DisplayClient (the delegated OutputSurface) is
created after the Display is, since it wants to have a pointer to the
Display. So we give the DisplayClient to the Display at the time of
Initialize().

Lastly, SurfaceDisplayOutputSurface was doing some shady things to avoid
binding the lost context callback on the shared context provider (shared
between the compositor's delegated and the display's OutputSurface) more
that once. It would avoid calling OutputSurface::BindToClient() and
implemented it partially itself. I changed this to call the parent but
just unset the callback with a comment explaining that we want it to go
to the Display (via its own OutputSurface) first, so we have it set up
the callback (which happens in Initialize).

The point of this whole thing was to work on merging the two delegated-
to-a-display output surface implementations: SurfaceDisplayOutputSurface
and PixelTestDelegatingOutputSurface. In the end this doesn't appear
feasible since the PixelTestDelegatingOutputSurface is meant for the
renderer, which can have a threaded compositor. In that case, the
Display, SurfaceManager, etc should be created, used and destroyed on the
compositor thread since they are not threadsafe. At least hopefully this
makes ownership more clear.

R=enne@chromium.org, fsamuel@chromium.org, jbauman@chromium.org,
sievers@chromium.org
BUG=487471
==========

to

==========
Delete OnscreenDisplayClient and TopLevelDisplayClient.

These classes just own Display and forward along the client calls to
the owner of themselves. Instead, have code own a cc::Display directly.

Part of this reworks how OutputSurface gets to the Display. Previously
the OnscreenDisplayClient would hold the OutputSurface created during
creation of the delegated OutputSurface to be given to the compositor.
But it wouldn't be given to the Display until the compositor bound the
delegated OutputSurface from LayerTreeHostImpl.

Now, we give the display's OutputSurface to it at construction time of
the Display. The Display will continue to bind it when it is
Initialize()'d by the delegated output surface in the compositor being
bound. However, now the DisplayClient (the delegated OutputSurface) is
created after the Display is, since it wants to have a pointer to the
Display. So we give the DisplayClient to the Display at the time of
Initialize().

Lastly, SurfaceDisplayOutputSurface was doing some shady things to avoid
binding the lost context callback on the shared context provider (shared
between the compositor's delegated and the display's OutputSurface) more
that once. It would avoid calling OutputSurface::BindToClient() and
implemented it partially itself. I changed this to call the parent but
just unset the callback with a comment explaining that we want it to go
to the Display (via its own OutputSurface) first, so we have it set up
the callback (which happens in Initialize).

The point of this whole thing was to work on merging the two delegated-
to-a-display output surface implementations: SurfaceDisplayOutputSurface
and PixelTestDelegatingOutputSurface. In the end this doesn't appear
feasible since the PixelTestDelegatingOutputSurface is meant for the
renderer, which can have a threaded compositor. In that case, the
Display, SurfaceManager, etc should be created, used and destroyed on the
compositor thread since they are not threadsafe. At least hopefully this
makes ownership more clear.

R=enne@chromium.org, fsamuel@chromium.org, jbauman@chromium.org,
sievers@chromium.org
BUG=487471
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[danakj, 2016-06-02 00:36:27]

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

[commit-bot: I haz the power, 2016-06-02 00:37:37]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2036563002/20001

[commit-bot: I haz the power, 2016-06-02 00:51:02]

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

[commit-bot: I haz the power, 2016-06-02 00:51:03]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[danakj, 2016-06-02 00:55:41]

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

[danakj, 2016-06-02 00:56:02]

danakj@chromium.org changed reviewers:
+ boliu@chromium.org

[danakj, 2016-06-02 00:56:03]

+boliu for webview (will TBR, just renaming the interface)

[enne (OOO), 2016-06-02 00:56:53]

lgtm, this is really good cleanup.

I really like "display output surface" vs "compositor output surface" as names
too.

[commit-bot: I haz the power, 2016-06-02 00:57:28]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2036563002/40001

[jbauman, 2016-06-02 01:01:09]

lgtm

[boliu, 2016-06-02 01:04:52]

On 2016/06/02 00:56:03, danakj wrote:
> +boliu for webview (will TBR, just renaming the interface)

rs lgtm

[commit-bot: I haz the power, 2016-06-02 01:10:38]

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

[commit-bot: I haz the power, 2016-06-02 01:10:39]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_compile_dbg on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)

[danakj, 2016-06-02 01:47:32]

Now with a webview that compiles. Had to fix how/where the Display is
constructed and initialized.

[danakj, 2016-06-02 01:48:16]

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

[commit-bot: I haz the power, 2016-06-02 01:49:16]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2036563002/60001

[boliu, 2016-06-02 01:53:48]

On 2016/06/02 01:47:32, danakj wrote:
> Now with a webview that compiles. Had to fix how/where the Display is
> constructed and initialized.

still lgtm

[commit-bot: I haz the power, 2016-06-02 02:13:07]

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

[commit-bot: I haz the power, 2016-06-02 02:13:09]

Dry run: Try jobs failed on following builders:
  linux_blink_rel on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/8...)
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[danakj, 2016-06-02 19:50:11]

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

[commit-bot: I haz the power, 2016-06-02 19:50:53]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/100001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2036563002/100001

[no sievers, 2016-06-02 21:16:42]

android lgtm

[commit-bot: I haz the power, 2016-06-02 21:18:31]

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

[commit-bot: I haz the power, 2016-06-02 21:18:35]

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

[danakj, 2016-06-02 21:48:23]

The CQ bit was checked by danakj@chromium.org

[danakj, 2016-06-02 21:48:24]

The patchset sent to the CQ was uploaded after l-g-t-m from
fsamuel@chromium.org, enne@chromium.org, jbauman@chromium.org,
boliu@chromium.org, sievers@chromium.org
Link to the patchset: https://codereview.chromium.org/2036563002/#ps120001
(title: "onscreendisplayclient: exportedbase")

[commit-bot: I haz the power, 2016-06-02 21:49:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2036563002/120001

[commit-bot: I haz the power, 2016-06-03 01:49:36]

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

[commit-bot: I haz the power, 2016-06-03 01:49:37]

Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[danakj, 2016-06-10 00:10:03]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2016-06-10 00:10:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/120001

[commit-bot: I haz the power, 2016-06-10 02:12:17]

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

[commit-bot: I haz the power, 2016-06-10 02:12:19]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_TIMED_OUT, no build
URL)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_TIMED_OUT, no build URL)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_TIMED_OUT, no build URL)

[danakj, 2016-06-10 17:14:13]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2016-06-10 17:14:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/120001

[commit-bot: I haz the power, 2016-06-10 18:56:46]

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

[commit-bot: I haz the power, 2016-06-10 18:56:47]

Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[boliu, 2016-06-10 23:10:33]

ahh, those webview failures are not flakes

And my earlier comment on chat that HardwareRenderer constructor can run GL is
not actually true. But I believe the right thing to do is to make it true, so..
patch this in pls: https://codereview.chromium.org/2063523002/

[boliu, 2016-06-10 23:16:13]

Not from bots this time. I patched this in, built webview, and noticed all
apps are locking up when they load webview..

On Fri, Jun 10, 2016 at 4:11 PM, Dana Jansens <danakj@chromium.org> wrote:

> On Fri, Jun 10, 2016 at 4:10 PM, <boliu@chromium.org> wrote:
>
>> ahh, those webview failures are not flakes
>>
>> And my earlier comment on chat that HardwareRenderer constructor can run
>> GL is
>> not actually true. But I believe the right thing to do is to make it
>> true, so..
>> patch this in pls: https://codereview.chromium.org/2063523002/
>>
>
> Thanks.. I was just trying to get an android device going. I completely
> failed to find the error messages that occured tho from the bot page. Did
> you find the smoking gun there?
>
>
>>
>>
>> https://codereview.chromium.org/2036563002/
>>
>
>

-- 
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.

[danakj, 2016-06-10 23:19:37]

Patchset #9 (id:160001) has been deleted

[danakj, 2016-06-10 23:19:49]

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

[danakj, 2016-06-10 23:20:02]

Added ScopedAllowGL around the HardwareRenderer constructor.

[danakj, 2016-06-10 23:20:12]

On Fri, Jun 10, 2016 at 4:10 PM, <boliu@chromium.org> wrote:

> ahh, those webview failures are not flakes
>
> And my earlier comment on chat that HardwareRenderer constructor can run
> GL is
> not actually true. But I believe the right thing to do is to make it true,
> so..
> patch this in pls: https://codereview.chromium.org/2063523002/
>

Thanks.. I was just trying to get an android device going. I completely
failed to find the error messages that occured tho from the bot page. Did
you find the smoking gun there?


>
>
> https://codereview.chromium.org/2036563002/
>

-- 
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.

[commit-bot: I haz the power, 2016-06-10 23:20:24]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/180001

[danakj, 2016-06-10 23:20:45]

The CQ bit was unchecked by danakj@chromium.org

[danakj, 2016-06-10 23:20:50]

The CQ bit was checked by danakj@chromium.org

[danakj, 2016-06-10 23:20:51]

The patchset sent to the CQ was uploaded after l-g-t-m from
fsamuel@chromium.org, enne@chromium.org, boliu@chromium.org,
jbauman@chromium.org, sievers@chromium.org
Link to the patchset: https://codereview.chromium.org/2036563002/#ps180001
(title: "onscreendisplayclient:
webview-scoped-allow-gl-for-hardwarerenderer-constructor")

[commit-bot: I haz the power, 2016-06-10 23:21:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/180001

[commit-bot: I haz the power, 2016-06-11 00:35:39]

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

[commit-bot: I haz the power, 2016-06-11 00:35:41]

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

[danakj, 2016-06-11 00:40:32]

The CQ bit was checked by danakj@chromium.org

[commit-bot: I haz the power, 2016-06-11 00:41:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2036563002/180001

[commit-bot: I haz the power, 2016-06-11 01:39:52]

Committed patchset #9 (id:180001)

[commit-bot: I haz the power, 2016-06-11 01:39:57]

CQ bit was unchecked

[commit-bot: I haz the power, 2016-06-11 01:41:08]

Description was changed from

==========
Delete OnscreenDisplayClient and TopLevelDisplayClient.

These classes just own Display and forward along the client calls to
the owner of themselves. Instead, have code own a cc::Display directly.

Part of this reworks how OutputSurface gets to the Display. Previously
the OnscreenDisplayClient would hold the OutputSurface created during
creation of the delegated OutputSurface to be given to the compositor.
But it wouldn't be given to the Display until the compositor bound the
delegated OutputSurface from LayerTreeHostImpl.

Now, we give the display's OutputSurface to it at construction time of
the Display. The Display will continue to bind it when it is
Initialize()'d by the delegated output surface in the compositor being
bound. However, now the DisplayClient (the delegated OutputSurface) is
created after the Display is, since it wants to have a pointer to the
Display. So we give the DisplayClient to the Display at the time of
Initialize().

Lastly, SurfaceDisplayOutputSurface was doing some shady things to avoid
binding the lost context callback on the shared context provider (shared
between the compositor's delegated and the display's OutputSurface) more
that once. It would avoid calling OutputSurface::BindToClient() and
implemented it partially itself. I changed this to call the parent but
just unset the callback with a comment explaining that we want it to go
to the Display (via its own OutputSurface) first, so we have it set up
the callback (which happens in Initialize).

The point of this whole thing was to work on merging the two delegated-
to-a-display output surface implementations: SurfaceDisplayOutputSurface
and PixelTestDelegatingOutputSurface. In the end this doesn't appear
feasible since the PixelTestDelegatingOutputSurface is meant for the
renderer, which can have a threaded compositor. In that case, the
Display, SurfaceManager, etc should be created, used and destroyed on the
compositor thread since they are not threadsafe. At least hopefully this
makes ownership more clear.

R=enne@chromium.org, fsamuel@chromium.org, jbauman@chromium.org,
sievers@chromium.org
BUG=487471
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Delete OnscreenDisplayClient and TopLevelDisplayClient.

These classes just own Display and forward along the client calls to
the owner of themselves. Instead, have code own a cc::Display directly.

Part of this reworks how OutputSurface gets to the Display. Previously
the OnscreenDisplayClient would hold the OutputSurface created during
creation of the delegated OutputSurface to be given to the compositor.
But it wouldn't be given to the Display until the compositor bound the
delegated OutputSurface from LayerTreeHostImpl.

Now, we give the display's OutputSurface to it at construction time of
the Display. The Display will continue to bind it when it is
Initialize()'d by the delegated output surface in the compositor being
bound. However, now the DisplayClient (the delegated OutputSurface) is
created after the Display is, since it wants to have a pointer to the
Display. So we give the DisplayClient to the Display at the time of
Initialize().

Lastly, SurfaceDisplayOutputSurface was doing some shady things to avoid
binding the lost context callback on the shared context provider (shared
between the compositor's delegated and the display's OutputSurface) more
that once. It would avoid calling OutputSurface::BindToClient() and
implemented it partially itself. I changed this to call the parent but
just unset the callback with a comment explaining that we want it to go
to the Display (via its own OutputSurface) first, so we have it set up
the callback (which happens in Initialize).

The point of this whole thing was to work on merging the two delegated-
to-a-display output surface implementations: SurfaceDisplayOutputSurface
and PixelTestDelegatingOutputSurface. In the end this doesn't appear
feasible since the PixelTestDelegatingOutputSurface is meant for the
renderer, which can have a threaded compositor. In that case, the
Display, SurfaceManager, etc should be created, used and destroyed on the
compositor thread since they are not threadsafe. At least hopefully this
makes ownership more clear.

R=enne@chromium.org, fsamuel@chromium.org, jbauman@chromium.org,
sievers@chromium.org
BUG=487471
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/324faea6be5251efbffb7438876478500b5532cf
Cr-Commit-Position: refs/heads/master@{#399348}
==========

[commit-bot: I haz the power, 2016-06-11 01:41:10]

Patchset 9 (id:??) landed as
https://crrev.com/324faea6be5251efbffb7438876478500b5532cf
Cr-Commit-Position: refs/heads/master@{#399348}