Completed the implementation for PPB_Graphics3D interface. Mostly copied from the implementations...

Completed the implementation for PPB_Graphics3D interface.
- Mostly copied from the implementations for PPB_Surface3D and PPB_Context3D.
- Added the proxy implementation
- Refactored common code between host and plugin side into a common class.

I will send the changes to bind Graphics3D with Instance and OpenGLES2 interface in a separate patch.

BUG=86370, 78087
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=92885

[piman, 2011-04-12 03:23:39]

2 comments.
I'd invite you to look at the proxy code in ppapi/proxy. We'll need a functional
proxy before we can switch.

http://codereview.chromium.org/6824006/diff/5001/webkit/plugins/ppapi/ppb_gra...
File webkit/plugins/ppapi/ppb_graphics_3d_impl.cc (right):

http://codereview.chromium.org/6824006/diff/5001/webkit/plugins/ppapi/ppb_gra...
webkit/plugins/ppapi/ppb_graphics_3d_impl.cc:128: const int32_t* attrib_list) {
Somewhere, something needs to parse the attrib_list to extract the initial size.
Note that similarly to SwapBuffers (see below), we have to check before calling
gles2_impl()->ResizeCHROMIUM
That being said, we can add parameters to CreateContext3D to pass in the initial
size (today we just start with 1x1).

http://codereview.chromium.org/6824006/diff/5001/webkit/plugins/ppapi/ppb_gra...
webkit/plugins/ppapi/ppb_graphics_3d_impl.cc:193: DCHECK(gles2_impl());
This DCHECK will fail when the interface is proxied (in the case CreateRaw gets
called, instead of Create). The plugin side is responsible for adding the
SwapBuffers command to the command buffers. That's why the PPB_Surface3D_Impl
code tests for it, and doesn't call gles2_impl()->SwapBuffers() if gles2_impl is
NULL

[piman, 2011-04-12 03:25:36]

On Mon, Apr 11, 2011 at 8:23 PM, <piman@chromium.org> wrote:

> 2 comments.
> I'd invite you to look at the proxy code in ppapi/proxy. We'll need a
> functional
> proxy before we can switch.
>

BTW, I think we can change BindGraphics to also accept a graphics_3d
resource (on top of graphics_2d and surface_3d) to allow for both interfaces
to co-exist and make an easier transition.

Antoine

[alokp, 2011-07-15 18:14:52]

PTAL

[piman, 2011-07-15 18:38:11]

LGTM
It mostly looks like copy and paste from the Context3D stuff, but hopefully it
will go away soon - maintaining both could be a nightmare.

http://codereview.chromium.org/6824006/diff/8001/webkit/plugins/ppapi/ppb_gra...
File webkit/plugins/ppapi/ppb_graphics_3d_impl.cc (right):

http://codereview.chromium.org/6824006/diff/8001/webkit/plugins/ppapi/ppb_gra...
webkit/plugins/ppapi/ppb_graphics_3d_impl.cc:219: // compositor is busy.
We really need to wait here, otherwise the plugin may keep rendering frames
(using CPU and GPU) that will never be displayed.
That being said, once http://codereview.chromium.org/7253052/ gets in, we can
kick the compositor directly from DoSwapBuffers, so that we don't need to wait
for an extra round trip - but we'll still want to wait until ViewFlushedPaint
before sending the ack.

[brettw, 2011-07-15 21:10:18]

LGTM rubberstamp based on piman's review in case you need some owners thing.

http://codereview.chromium.org/6824006/diff/8001/webkit/plugins/ppapi/ppb_gra...
File webkit/plugins/ppapi/ppb_graphics_3d_impl.h (right):

http://codereview.chromium.org/6824006/diff/8001/webkit/plugins/ppapi/ppb_gra...
webkit/plugins/ppapi/ppb_graphics_3d_impl.h:30: // Resource override.
I think this was better as ResourceObjectBase since that's really where this is
coming from.

[commit-bot: I haz the power, 2011-07-18 20:58:24]

Change committed as 92885