Add Pepper support for several GL extensions

Add Pepper support for several GL extensions

Add support to the command buffer code generator to generate multiple pepper interfaces, and use that to generate interfaces for ANGLE_instanced_arrays, ANGLE_framebuffer_blit, ANGLE_framebuffer_multisample, CHROMIUM_enable_feature, and CHROMIUM_map_sub.

BUG=93148
TEST=

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

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

[nfullagar, 2012-02-16 23:25:43]

also, you probably want to edit
trunk/src/ppapi/native_client/src/shared/ppapi_proxy/browser_globals.cc, around
line 187 (search for enable_3d_interface) and add the new extension interfaces.

https://chromiumcodereview.appspot.com/9420017/diff/2001/ppapi/c/ppb_opengles2.h
File ppapi/c/ppb_opengles2.h (right):

https://chromiumcodereview.appspot.com/9420017/diff/2001/ppapi/c/ppb_opengles...
ppapi/c/ppb_opengles2.h:353: void* (*MapTexSubImage2DCHROMIUM)(
If MapTexSubImage2DCHROMIUM is moving here, this CL could delete
ppapi/c/dev/ppb_gles_chromium_texture_mapping_dev.h
(but see comment below about dev vs. non-dev extensions) 
And remove #include ....ppb_gles_chromium_texture_mapping_dev.h from
corresponding files.

https://chromiumcodereview.appspot.com/9420017/diff/2001/ppapi/c/ppb_opengles...
ppapi/c/ppb_opengles2.h:357: void (*UnmapTexSubImage2DCHROMIUM)(PP_Resource
context, const void* mem);
Traditionally new PPAPI interfaces would hang out as a dev interface for a
while.  Are we sure we want to expose these right out of the gate as non-dev
interfaces?  Perhaps have a ppapi/c/dev/ppb_opengles2ext_dev.h to hold new
extensions before they come out of dev?

[jbauman, 2012-02-16 23:32:46]

On 2012/02/16 23:25:43, nfullagar wrote:
> also, you probably want to edit
> trunk/src/ppapi/native_client/src/shared/ppapi_proxy/browser_globals.cc,
around
> line 187 (search for enable_3d_interface) and add the new extension
interfaces.

Hmm, true. I feel like there's some room for consolidating all these locations.
> 
>
https://chromiumcodereview.appspot.com/9420017/diff/2001/ppapi/c/ppb_opengles2.h
> File ppapi/c/ppb_opengles2.h (right):
> 
>
https://chromiumcodereview.appspot.com/9420017/diff/2001/ppapi/c/ppb_opengles...
> ppapi/c/ppb_opengles2.h:353: void* (*MapTexSubImage2DCHROMIUM)(
> If MapTexSubImage2DCHROMIUM is moving here, this CL could delete
> ppapi/c/dev/ppb_gles_chromium_texture_mapping_dev.h
> (but see comment below about dev vs. non-dev extensions) 
> And remove #include ....ppb_gles_chromium_texture_mapping_dev.h from
> corresponding files.

Sure.
> 
>
https://chromiumcodereview.appspot.com/9420017/diff/2001/ppapi/c/ppb_opengles...
> ppapi/c/ppb_opengles2.h:357: void (*UnmapTexSubImage2DCHROMIUM)(PP_Resource
> context, const void* mem);
> Traditionally new PPAPI interfaces would hang out as a dev interface for a
> while.  Are we sure we want to expose these right out of the gate as non-dev
> interfaces?  Perhaps have a ppapi/c/dev/ppb_opengles2ext_dev.h to hold new
> extensions before they come out of dev?

No clue. I could add support to the code generator to be able to segregate new
interfaces into dev and not dev, although ppapi/lib/gl would then be restricted
to only call into stable interfaces. I don't know if it's worth it to do that,
given how little review these interfaces would have while in dev.

[jbauman, 2012-02-17 23:29:28]

Ok, I changed this so that all the new interfaces are dev interfaces.

On 2012/02/16 23:25:43, nfullagar wrote:
> also, you probably want to edit
> trunk/src/ppapi/native_client/src/shared/ppapi_proxy/browser_globals.cc,
around
> line 187 (search for enable_3d_interface) and add the new extension
interfaces.
> 
>
https://chromiumcodereview.appspot.com/9420017/diff/2001/ppapi/c/ppb_opengles2.h
> File ppapi/c/ppb_opengles2.h (right):
> 
>
https://chromiumcodereview.appspot.com/9420017/diff/2001/ppapi/c/ppb_opengles...
> ppapi/c/ppb_opengles2.h:353: void* (*MapTexSubImage2DCHROMIUM)(
> If MapTexSubImage2DCHROMIUM is moving here, this CL could delete
> ppapi/c/dev/ppb_gles_chromium_texture_mapping_dev.h
> (but see comment below about dev vs. non-dev extensions) 
> And remove #include ....ppb_gles_chromium_texture_mapping_dev.h from
> corresponding files.
> 
>
https://chromiumcodereview.appspot.com/9420017/diff/2001/ppapi/c/ppb_opengles...
> ppapi/c/ppb_opengles2.h:357: void (*UnmapTexSubImage2DCHROMIUM)(PP_Resource
> context, const void* mem);
> Traditionally new PPAPI interfaces would hang out as a dev interface for a
> while.  Are we sure we want to expose these right out of the gate as non-dev
> interfaces?  Perhaps have a ppapi/c/dev/ppb_opengles2ext_dev.h to hold new
> extensions before they come out of dev?

[nfullagar, 2012-02-18 00:18:03]

thx for the dev change.  couple more #include.  otherwise lgtm pending main
reviewer feedback

http://codereview.chromium.org/9420017/diff/6003/ppapi/proxy/interface_list.cc
File ppapi/proxy/interface_list.cc (right):

http://codereview.chromium.org/9420017/diff/6003/ppapi/proxy/interface_list.c...
ppapi/proxy/interface_list.cc:19: #include "ppapi/c/dev/ppb_message_loop_dev.h"
#include "ppapi/c/dev/ppb_opengles2ext_dev.h"

http://codereview.chromium.org/9420017/diff/6003/webkit/plugins/ppapi/plugin_...
File webkit/plugins/ppapi/plugin_module.cc (right):

http://codereview.chromium.org/9420017/diff/6003/webkit/plugins/ppapi/plugin_...
webkit/plugins/ppapi/plugin_module.cc:29: #include
"ppapi/c/dev/ppb_memory_dev.h"
#include "ppapi/c/dev/ppb_opengles2ext_dev.h"

[jbauman, 2012-02-21 22:14:21]

Antoine, do you want to review this, or would you prefer I get someone
different? You happened to be listed as an OWNER for all the files I modified.
:)

[jbauman, 2012-02-22 00:27:38]

Apparently Antoine is out, so adding gman@, brettw@, and darin@ for OWNERS
review (and possibly more review, if they want).

[greggman, 2012-02-22 00:53:05]

lgtm for the src/gpu part

http://codereview.chromium.org/9420017/diff/7025/gpu/command_buffer/build_gle...
File gpu/command_buffer/build_gles2_cmd_buffer.py (right):

http://codereview.chromium.org/9420017/diff/7025/gpu/command_buffer/build_gle...
gpu/command_buffer/build_gles2_cmd_buffer.py:738: ('', False),
You can leave this as is but my preference would be to label fields. 

_PEPPER_INTERFACES = [
{'name': Foo, 'dev': True},
...
];

http://codereview.chromium.org/9420017/diff/7025/gpu/command_buffer/build_gle...
gpu/command_buffer/build_gles2_cmd_buffer.py:5180: 
style: 2 blank lines between top level definitions

http://codereview.chromium.org/9420017/diff/7025/gpu/command_buffer/build_gle...
gpu/command_buffer/build_gles2_cmd_buffer.py:5211: 
style: 2 blank lines between top level definitions

[brettw, 2012-02-22 19:04:35]

Please specify who you need to review what, and only add one owner for one
thing.

[jbauman, 2012-02-22 19:06:00]

Ok, brettw for owners review of ppapi/ and webkit/plugins/ppapi.

[brettw, 2012-02-25 18:28:43]

lgtm

[piman, 2012-03-05 17:10:46]

Just to close the loop, did you check with Flash people about the API change for
PPB_GLESChromiumTextureMapping? Without special treatment it would break Flash.

[jbauman, 2012-03-05 20:56:30]

On 2012/03/05 17:10:46, piman wrote:
> Just to close the loop, did you check with Flash people about the API change
for
> PPB_GLESChromiumTextureMapping? Without special treatment it would break
Flash.

Yeah, I just left that api in when checking this in (one of the tests caught the
issue). We'll need to get them to change their code before we remove it.

[Antoine Labour, 2012-03-05 23:32:32]

On Mon, Mar 5, 2012 at 12:56 PM, <jbauman@chromium.org> wrote:

> On 2012/03/05 17:10:46, piman wrote:
>
>> Just to close the loop, did you check with Flash people about the API
>> change
>>
> for
>
>> PPB_**GLESChromiumTextureMapping? Without special treatment it would
>> break
>>
> Flash.
>
> Yeah, I just left that api in when checking this in (one of the tests
> caught the
> issue). We'll need to get them to change their code before we remove it.
>

Ok, great, thanks :)


>
>
http://codereview.chromium.**org/9420017/<http://codereview.chromium.org/9420...
>

[ilja, 2012-03-06 07:26:02]

Thanks for the warning, I prepared a change for vtl.

[viettrungluu, 2012-03-06 18:18:01]

On 2012/03/05 23:32:32, Antoine Labour wrote:
> On Mon, Mar 5, 2012 at 12:56 PM, <mailto:jbauman@chromium.org> wrote:
> 
> > On 2012/03/05 17:10:46, piman wrote:
> >
> >> Just to close the loop, did you check with Flash people about the API
> >> change
> >>
> > for
> >
> >> PPB_**GLESChromiumTextureMapping? Without special treatment it would
> >> break
> >>
> > Flash.
> >
> > Yeah, I just left that api in when checking this in (one of the tests
> > caught the
> > issue). We'll need to get them to change their code before we remove it.
> >
> 
> Ok, great, thanks :)
> 
> 
> >
> >
>
http://codereview.chromium.**org/9420017/%3Chttp://codereview.chromium.org/94...>
> >

I'd very much like to remain backwards compatible with early revisions of Chrome
(back to M18) without too much trouble. Could you hold off on removing the older
interface for a while?

(Obviously, we can work around that, but it'd be better if Chrome continued to
support the old interface, at least until M19 ships to Stable.)

[jbauman, 2012-03-06 20:15:38]

On 2012/03/06 18:18:01, viettrungluu wrote:
> On 2012/03/05 23:32:32, Antoine Labour wrote:
> > On Mon, Mar 5, 2012 at 12:56 PM, <mailto:jbauman@chromium.org> wrote:
> > 
> > > On 2012/03/05 17:10:46, piman wrote:
> > >
> > >> Just to close the loop, did you check with Flash people about the API
> > >> change
> > >>
> > > for
> > >
> > >> PPB_**GLESChromiumTextureMapping? Without special treatment it would
> > >> break
> > >>
> > > Flash.
> > >
> > > Yeah, I just left that api in when checking this in (one of the tests
> > > caught the
> > > issue). We'll need to get them to change their code before we remove it.
> > >
> > 
> > Ok, great, thanks :)
> > 
> > 
> > >
> > >
> >
>
http://codereview.chromium.**org/9420017/%253Chttp://codereview.chromium.org/...>
> > >
> 
> I'd very much like to remain backwards compatible with early revisions of
Chrome
> (back to M18) without too much trouble. Could you hold off on removing the
older
> interface for a while?
> 
> (Obviously, we can work around that, but it'd be better if Chrome continued to
> support the old interface, at least until M19 ships to Stable.)

Sure, keeping the old interface around for a while shouldn't be an issue.
Actually, it would probably be easiest to not switch to the new interface until
it's promoted to stable (hopefully by M19).