Expose GLES2Interface to cc

Expose GLES2Interface to cc

This exposes a gpu::gles2::GLES2Interface pointer to cc through the ContextProvider.  This is a way for the compositor to talk to the client side of the command buffer more directly, bypassing the blink::WebGraphicsContext3D indirection.  See the bug for the plan for using this new interface and deprecating WGC3D.

BUG=181120
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=238809

[jamesr, 2013-11-14 02:51:43]

I have a test strategy that I need to flesh out a bit before landing this or
it'll be super confusing to know which context to use where/when, but WDYT of
the hookup thus far?

[piman, 2013-11-14 18:30:09]

On 2013/11/14 02:51:43, jamesr wrote:
> I have a test strategy that I need to flesh out a bit before landing this or
> it'll be super confusing to know which context to use where/when, but WDYT of
> the hookup thus far?

IIUC you want (temporarily?) 2 (disconnected) contexts for
test_context_provider?
There are a few tests that set things up on the context and expect the
compositor to use it, but it's probably true that it's more the exception than
the norm. For those, will GLES2InterfaceStub be enough, once, I assume, we
change cc to use the GLES2Interface rather than WGC3D?

I guess I have a bit of a hard time to evaluate without seeing the test changes.

[jamesr, 2013-11-28 00:53:22]

One way it could work:

1.) Land this patch.  At this point, the two interfaces will map to the same
thing in production code.

2.) Land https://codereview.chromium.org/93283002 that adds a test context class
that inherits from GLES2InterfaceStub that is a clone of the
TestWebGraphicsContext3D stuff

3.) Land https://codereview.chromium.org/92593004/, which ports the program +
shader code to use GLES2Interface and the TestGLES2Interface class, extending
the test class and porting unit tests over as needed

4.) Repeat step 3 for different subsystems, gradually porting all production
code over to GLES2Interface and all test code over to TestGLES2Interface

5.) Remove TestWebGraphicsContext3D + WebGraphicsContext3D stubs

The biggest downside is that during the loop in step 4 we'll have two context
types exposed to cc and different tests will use different combinations.  In
production, the two interface will map to the same thing underneath so it
shouldn't cause problems but it might be really confusing for tests to have the
mix.  It also might be hard to port things over piecemeal especially for common
test harnesses that are used by lots of different tests.

Another approach to step 2+ would be to add a test class that inherits from
GLES2Interface and forwards things to TestWebGraphicsContext3D.  Then we could
port the production code over to GLES2Interface mostly leaving the tests
untouched and remove the production dependency on WGC3D almost immediately at
the cost of still having to port all the tests over one at a time.  This would
also mean having yet another copy of an interface that forwards one
manifestation of GLES2 to another, which is a bummer.  It's probably better
overall although I really don't want to type out the forwarding interface. 
Maybe over the break I'll work up enough gumption to try to either bastardize
the gpu/ generation scripts to do the heavy lifting for me or copy one of the
existing forwarding classes and search+replace it into shape.

[danakj, 2013-12-02 15:16:20]

On Wed, Nov 27, 2013 at 4:53 PM, <jamesr@chromium.org> wrote:

> One way it could work:
>
> 1.) Land this patch.  At this point, the two interfaces will map to the
> same
> thing in production code.
>
> 2.) Land https://codereview.chromium.org/93283002 that adds a test
> context class
> that inherits from GLES2InterfaceStub that is a clone of the
> TestWebGraphicsContext3D stuff
>
> 3.) Land https://codereview.chromium.org/92593004/, which ports the
> program +
> shader code to use GLES2Interface and the TestGLES2Interface class,
> extending
> the test class and porting unit tests over as needed
>
> 4.) Repeat step 3 for different subsystems, gradually porting all
> production
> code over to GLES2Interface and all test code over to TestGLES2Interface
>
> 5.) Remove TestWebGraphicsContext3D + WebGraphicsContext3D stubs
>
> The biggest downside is that during the loop in step 4 we'll have two
> context
> types exposed to cc and different tests will use different combinations.
>  In
> production, the two interface will map to the same thing underneath so it
> shouldn't cause problems but it might be really confusing for tests to
> have the
> mix.  It also might be hard to port things over piecemeal especially for
> common
> test harnesses that are used by lots of different tests.
>
> Another approach to step 2+ would be to add a test class that inherits from
> GLES2Interface and forwards things to TestWebGraphicsContext3D.  Then we
> could
> port the production code over to GLES2Interface mostly leaving the tests
> untouched and remove the production dependency on WGC3D almost immediately
> at
> the cost of still having to port all the tests over one at a time.  This
> would
> also mean having yet another copy of an interface that forwards one
> manifestation of GLES2 to another, which is a bummer.  It's probably better
> overall although I really don't want to type out the forwarding interface.
> Maybe over the break I'll work up enough gumption to try to either
> bastardize
> the gpu/ generation scripts to do the heavy lifting for me or copy one of
> the
> existing forwarding classes and search+replace it into shape.
>

Ya, I still like this latter idea best. Did you have any ideas/luck with
automating it?

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jamesr, 2013-12-04 01:32:07]

OK - I think we have a plan for finishing the transition that's solid enough to
proceed.  My main concern is that we might end up in a confusing place where cc
is talking to GLES2Interface sometimes and WGC3D other times, but I think we can
deal with that.  I sent an overview out to graphics-dev@ and have a first patch
showing the new strategy up here:

https://codereview.chromium.org/93433004/

Can I get an LG?

[piman, 2013-12-04 02:01:11]

LGTM+nit

https://codereview.chromium.org/54463007/diff/90001/cc/test/test_web_graphics...
File cc/test/test_web_graphics_context_3d.h (right):

https://codereview.chromium.org/54463007/diff/90001/cc/test/test_web_graphics...
cc/test/test_web_graphics_context_3d.h:201: unsigned
AllocateTestTextureForExternalUse();
nit: leftover from another patch?

[jamesr, 2013-12-04 02:06:48]

On 2013/12/04 02:01:11, piman wrote:
>
https://codereview.chromium.org/54463007/diff/90001/cc/test/test_web_graphics...
> cc/test/test_web_graphics_context_3d.h:201: unsigned
> AllocateTestTextureForExternalUse();
> nit: leftover from another patch?

Oops, yes.  Will nuke.

[commit-bot: I haz the power, 2013-12-04 19:07:16]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamesr@chromium.org/54463007/130001

[commit-bot: I haz the power, 2013-12-04 21:18:42]

Commit queue failed due to new patchset.

[commit-bot: I haz the power, 2013-12-04 21:18:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jamesr@chromium.org/54463007/150001

[commit-bot: I haz the power, 2013-12-04 23:22:28]

Change committed as 238809