Implemented PGL library, an EGL like API for Pepper. Updated Pepper test plug...

Implemented PGL library, an EGL like API for Pepper. Updated Pepper test plugin to use it.
TEST=none yet
BUG=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=36268

[alokp, 2010-01-14 02:35:22]

Wow Al - you rock!

A couple of things:
1. I think Nicholas and Gregg should also review this.
2. Today I got a little confused regarding pepper and nacl. Gregg mentioned that
pepper should only support command buffer API, no gles2 implementation. The
gles2 implementation will only be available from nacl sdk. Did I misunderstand
something? It would help me a lot if someone can explain what API will be
available from trusted pepper and untrusted nacl module. Where does pgl fit into
all this?

Thanks,
-Alok

[sehr (please use chromium), 2010-01-14 04:21:56]

On 2010/01/14 02:35:22, alokp wrote:
> Wow Al - you rock!
> 
> A couple of things:
> 1. I think Nicholas and Gregg should also review this.
> 2. Today I got a little confused regarding pepper and nacl. Gregg mentioned
that
> pepper should only support command buffer API, no gles2 implementation. The
> gles2 implementation will only be available from nacl sdk. Did I misunderstand
> something? It would help me a lot if someone can explain what API will be
> available from trusted pepper and untrusted nacl module. Where does pgl fit
into
> all this?
> 
> Thanks,
> -Alok

LGTM.  I'll wait until your CL is in to submit.

[apatrick_chromium, 2010-01-14 04:49:52]

+nfullagar +gman as requested.

There are typos and indentation errors in pgl.cc. I'll get to them tomorrow but
please feel free to help out with comments!

[alokp, 2010-01-14 04:59:25]

lgtm

http://codereview.chromium.org/545052/diff/1/6
File webkit/tools/pepper_test_plugin/plugin_object.h (right):

http://codereview.chromium.org/545052/diff/1/6#newcode33
webkit/tools/pepper_test_plugin/plugin_object.h:33: #include
"gpu/command_buffer/client/gles2_implementation.h"
do you still need to include gles2_implementation.h

[gregoryd, 2010-01-14 07:45:12]

LGTM

http://codereview.chromium.org/545052/diff/1/8
File gpu/pgl/pgl.cc (right):

http://codereview.chromium.org/545052/diff/1/8#newcode12
gpu/pgl/pgl.cc:12: #define THREAD_LOCAL __declspec(thread)
This is probably already defined in base or somewhere else

[nfullagar, 2010-01-14 17:36:55]

http://codereview.chromium.org/545052/diff/1/8
File gpu/pgl/pgl.cc (right):

http://codereview.chromium.org/545052/diff/1/8#newcode122
gpu/pgl/pgl.cc:122: gles2_implementation_->SwapBuffers();
Apologies if this has been done already else where in implementation.  I found I
needed to also make a call to gles2_implementation_->WaitForCmd().  Otherwise,
simple GL renderings (==small amount of space in the cmd buffer, but could still
be fill rate intense) could cause the app to start rendering 10s or 100s of
frames in advance of what was being presented to the screen, esp if vsync is
enabled.  This can make menu navigation challenging, especially when the mouse
cursor is rendered with gl commands.

There are several places this could go, ie. glFlush(), glFinish(),
pglSwapBuffers(), SwapBuffers().  For pglSwapBuffers(), perhaps have this be an
option in the graphics 3D context during initialization?

If vsync is enabled, not only should pglSwapBuffers wait for the commands to
flush, it should probably wait for the glSwapBuffers to complete on the server
side, so an application is governed by vsync (or whatever the virtual eq. is on
lcd displays)

[apatrick_chromium, 2010-01-14 19:39:44]

http://codereview.chromium.org/545052/diff/1/8
File gpu/pgl/pgl.cc (right):

http://codereview.chromium.org/545052/diff/1/8#newcode12
gpu/pgl/pgl.cc:12: #define THREAD_LOCAL __declspec(thread)
On 2010/01/14 07:45:12, gregoryd wrote:
> This is probably already defined in base or somewhere else

This needs to be compiled into nexes so we've avoided using anything in base.

http://codereview.chromium.org/545052/diff/1/8#newcode122
gpu/pgl/pgl.cc:122: gles2_implementation_->SwapBuffers();
On 2010/01/14 17:36:55, nfullagar wrote:
> Apologies if this has been done already else where in implementation.  I found
I
> needed to also make a call to gles2_implementation_->WaitForCmd(). 
Otherwise,
> simple GL renderings (==small amount of space in the cmd buffer, but could
still
> be fill rate intense) could cause the app to start rendering 10s or 100s of
> frames in advance of what was being presented to the screen, esp if vsync is
> enabled.  This can make menu navigation challenging, especially when the
mouse
> cursor is rendered with gl commands.
> 
> There are several places this could go, ie. glFlush(), glFinish(),
> pglSwapBuffers(), SwapBuffers().  For pglSwapBuffers(), perhaps have this be
an
> option in the graphics 3D context during initialization?
> 
> If vsync is enabled, not only should pglSwapBuffers wait for the commands to
> flush, it should probably wait for the glSwapBuffers to complete on the
server
> side, so an application is governed by vsync (or whatever the virtual eq. is
on
> lcd displays)
> 
> 

I think gman fixed this. If it turns out otherwise, I'll fix it.

http://codereview.chromium.org/545052/diff/1/6
File webkit/tools/pepper_test_plugin/plugin_object.h (right):

http://codereview.chromium.org/545052/diff/1/6#newcode33
webkit/tools/pepper_test_plugin/plugin_object.h:33: #include
"gpu/command_buffer/client/gles2_implementation.h"
On 2010/01/14 04:59:25, alokp wrote:
> do you still need to include gles2_implementation.h

Done.