Extract method: CreateDelegatedLayerForFrameProvider

Extract method: CreateDelegatedLayerForFrameProvider

Embedders may want to apply independent filters on layers for their
browser GUI. If they need two instances of a GUI element then they are
forced to add two layers with the same content in them. In the DRL case
an access to DelegatedFrameProvider needed. With this change embedders
can create secondary DRL layers easily.

https://groups.google.com/a/chromium.org/forum/
    /#!topic/graphics-dev/xZPzMnBe6dg

R=sievers@chromium.org,aelias@chromium.org
BUG=

Committed: https://crrev.com/abd0e10a4da46eddba5e75118972e74a3f432621
Cr-Commit-Position: refs/heads/master@{#294146}

[loysob, 2014-09-01 15:09:34]

This is my first CL. Could you review my changes, please?

The original discussion is here:

https://groups.google.com/a/chromium.org/d/msg/graphics-dev/xZPzMnBe6dg/G9gGv...

I'm just wondering if Dana Jansens needed as a reviewer here.

Thanks!

[aelias_OOO_until_Jul13, 2014-09-03 20:12:03]

Sorry, the Chromium project doesn't officially support embedders other than
Chrome for Android, so it doesn't make sense to add a new ContentViewCore API. 
Even if I allowed it to land now, your new API is likely to get deleted in a
future refactoring when someone else observes it's unused, so you'd just
experience breakage a few months from now.  I would approve just the
RenderWidgetHostViewAndroid part of this patch though, as it's a nice
refactoring on its own.  I recommend just landing that upstream and maintaining
the ContentViewCore API in your private branch.

https://codereview.chromium.org/527073002/diff/1/content/browser/android/cont...
File content/browser/android/content_view_core_impl.cc (right):

https://codereview.chromium.org/527073002/diff/1/content/browser/android/cont...
content/browser/android/content_view_core_impl.cc:652: if (!view) {
nit: no braces here

[loysob, 2014-09-04 09:00:28]

On 2014/09/03 20:12:03, aelias wrote:
> Sorry, the Chromium project doesn't officially support embedders other than
> Chrome for Android, so it doesn't make sense to add a new ContentViewCore API.

> Even if I allowed it to land now, your new API is likely to get deleted in a
> future refactoring when someone else observes it's unused, so you'd just
> experience breakage a few months from now.  I would approve just the
> RenderWidgetHostViewAndroid part of this patch though, as it's a nice
> refactoring on its own.  I recommend just landing that upstream and
maintaining
> the ContentViewCore API in your private branch.
> 
>
https://codereview.chromium.org/527073002/diff/1/content/browser/android/cont...
> File content/browser/android/content_view_core_impl.cc (right):
> 
>
https://codereview.chromium.org/527073002/diff/1/content/browser/android/cont...
> content/browser/android/content_view_core_impl.cc:652: if (!view) {
> nit: no braces here

Thank you, aelias!

That's ok. Let us live with just RWHVA changes only. We have
ContentViewCoreImpl::GetRenderWidgetHostViewAndroid() anyway.

[aelias_OOO_until_Jul13, 2014-09-04 18:20:02]

lgtm

[no sievers, 2014-09-09 18:26:48]

On 2014/09/04 09:00:28, loysob wrote:
> On 2014/09/03 20:12:03, aelias wrote:
> > Sorry, the Chromium project doesn't officially support embedders other than
> > Chrome for Android, so it doesn't make sense to add a new ContentViewCore
API.
> 
> > Even if I allowed it to land now, your new API is likely to get deleted in a
> > future refactoring when someone else observes it's unused, so you'd just
> > experience breakage a few months from now.  I would approve just the
> > RenderWidgetHostViewAndroid part of this patch though, as it's a nice
> > refactoring on its own.  I recommend just landing that upstream and
> maintaining
> > the ContentViewCore API in your private branch.
> > 
> >
>
https://codereview.chromium.org/527073002/diff/1/content/browser/android/cont...
> > File content/browser/android/content_view_core_impl.cc (right):
> > 
> >
>
https://codereview.chromium.org/527073002/diff/1/content/browser/android/cont...
> > content/browser/android/content_view_core_impl.cc:652: if (!view) {
> > nit: no braces here
> 
> Thank you, aelias!
> 
> That's ok. Let us live with just RWHVA changes only. We have
> ContentViewCoreImpl::GetRenderWidgetHostViewAndroid() anyway.

lgtm. But this does not create a content-public embedder interface still,
because RWHV is not public (and neither is CVCImpl exposing the RWHV). It's also
a bit problematic, because it exposes a reference to the internal frame
provider. There are situations in RWHVA where we destroy the frame provider and
later create a new one, which the other layer(s) you exposed are not aware of.
(And it doesn't seem like a good idea to start exposing signals for those
either.)

[loysob, 2014-09-10 07:50:23]

The CQ bit was checked by loysob@yandex-team.ru

[commit-bot: I haz the power, 2014-09-10 07:51:32]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/loysob@yandex-team.ru/527073002/20001

[commit-bot: I haz the power, 2014-09-10 08:59:42]

Committed patchset #2 (id:20001) as 45c2fca686d19be74ac94252cddcc4aad2eda106

[commit-bot: I haz the power, 2014-09-10 10:56:11]

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