Convert most remaining resources to use the API/thunk system. The significant

Convert most remaining resources to use the API/thunk system. The significant
changes here are around the 3D API. Having separate files for the texture
mapping interface is no longer necessary for the proxy and the
implementation.

This also removes the uses of the "old" dynamic casting system (using
"GetAs") for other resources that I could find.

TEST=ui tests
BUG=none
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=90096

[alokp, 2011-06-20 16:36:03]

GL part lgtm. May be piman should look at the trusted 3D API.

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_context_3d_p...
File ppapi/proxy/ppb_context_3d_proxy.h (right):

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_context_3d_p...
ppapi/proxy/ppb_context_3d_proxy.h:38: public ::ppapi::thunk::PPB_Context3D_API
{
nit: is it necessary to prepend :: to ppapi::thunk::?

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_opengles2_pr...
File ppapi/proxy/ppb_opengles2_proxy.cc (right):

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_opengles2_pr...
ppapi/proxy/ppb_opengles2_proxy.cc:16: #include
"ppapi/shared_impl/resource_object_base.h"
This file is supposed to be auto-generated. Not a problem if you hand edited it,
I can change the script in subsequent CL to generate this output.

[brettw, 2011-06-20 19:31:03]

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_context_3d_p...
File ppapi/proxy/ppb_context_3d_proxy.h (right):

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_context_3d_p...
ppapi/proxy/ppb_context_3d_proxy.h:38: public ::ppapi::thunk::PPB_Context3D_API
{
Nope, got used to doing it for webkit/plugins/ppapi where it is necessary.

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_opengles2_pr...
File ppapi/proxy/ppb_opengles2_proxy.cc (right):

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_opengles2_pr...
ppapi/proxy/ppb_opengles2_proxy.cc:16: #include
"ppapi/shared_impl/resource_object_base.h"
I searched for a while and couldn't find the original anywhere. Where is it? Can
the generated output list how it was generated?

[brettw, 2011-06-20 19:43:51]

+piman for trusted 3D API

[alokp, 2011-06-20 19:50:46]

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_opengles2_pr...
File ppapi/proxy/ppb_opengles2_proxy.cc (right):

http://codereview.chromium.org/7206016/diff/1073/ppapi/proxy/ppb_opengles2_pr...
ppapi/proxy/ppb_opengles2_proxy.cc:16: #include
"ppapi/shared_impl/resource_object_base.h"
It is generated using gpu/command_buffer/build_gles2_cmd_buffer.py. Sorry the
script has become messy with all the new functionality for ppapi. It is on my
TODO list to separate out the ppapi stuff.

[brettw, 2011-06-20 20:23:36]

I updated the generation script and added a comment about what generates the
files. Then I used it to make new versions of the pepper proxy and impl.

[piman, 2011-06-20 20:26:14]

http://codereview.chromium.org/7206016/diff/1073/ppapi/thunk/ppb_context_3d_a...
File ppapi/thunk/ppb_context_3d_api.h (right):

http://codereview.chromium.org/7206016/diff/1073/ppapi/thunk/ppb_context_3d_a...
ppapi/thunk/ppb_context_3d_api.h:37: // GLESChromiumTextureMapping.
Why are these piggy-backing on the PPB_Context3D_API ? They're a lot more like
all the other GL calls (in PPB_OpenGLES2_Dev) than the above... We should be
consistent and either put the GL calls here, or move these 2 calls out and
handle them the same way as the GL calls.

http://codereview.chromium.org/7206016/diff/1073/webkit/plugins/ppapi/ppb_con...
File webkit/plugins/ppapi/ppb_context_3d_impl.h (right):

http://codereview.chromium.org/7206016/diff/1073/webkit/plugins/ppapi/ppb_con...
webkit/plugins/ppapi/ppb_context_3d_impl.h:104: // TODO(brettw) in which cases
is this NULL?
I don't think it should be NULL, except for a botched initialization, but then
the PPB_Context3D_Impl should get destroyed quickly...

[brettw, 2011-06-20 21:37:11]

http://codereview.chromium.org/7206016/diff/1073/ppapi/thunk/ppb_context_3d_a...
File ppapi/thunk/ppb_context_3d_api.h (right):

http://codereview.chromium.org/7206016/diff/1073/ppapi/thunk/ppb_context_3d_a...
ppapi/thunk/ppb_context_3d_api.h:37: // GLESChromiumTextureMapping.
Everything "should" be like this and go through the thunk layer. The advantage
of the thunk layer is that it saves you from having to implement the resource
conversion multiple times, and allows you to write object-oriented code in the
impl and the proxy.

But if I were to do that for the GL calls, that would be >100 virtual functions
in each of these places which can't be autogenerated. I can do things, like
maybe autogenerate a header file with a define for the declaration of all of
these functions, and then use that in both the proxy and the impl, then
autogenerate another file to forward these from the Context to the gles_impl.

It seemed less complexity overall to treat the autogenerated GL functions as
special and bypass the thunk layer.