GPUProcessor uses O3D command buffer service to render to a window....

GPUProcessor uses O3D command buffer service to render to a window.
Added libraries that contain a subset of the O3D command buffer code independent on NaCl.
Extracted Upcall interface from CommandBufferEngine.

Now this works in JavaScript to clear the GPU plugin element to a random color:

   // BEGIN_FRAME
   sharedMemory.setInt32(putOffset++, 0x00000201);
   
   // CLEAR
   sharedMemory.setInt32(putOffset++, 0x00000408);
   sharedMemory.setInt32(putOffset++, 7);
   sharedMemory.setFloat(putOffset++, Math.random());
   sharedMemory.setFloat(putOffset++, Math.random());
   sharedMemory.setFloat(putOffset++, Math.random());
   sharedMemory.setFloat(putOffset++, 1);
   sharedMemory.setFloat(putOffset++, 0.5);
   sharedMemory.setInt32(putOffset++, 0);

   // END_FRAME
   sharedMemory.setInt32(putOffset++, 0x00000301);



TEST=none
BUG=none


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

[gman, 2009-09-24 01:44:04]

Please fix the lint errors. I think all but 1 are fixable.

Also, this seems like a fine first start but if you really want to expose shared
memory to JavaScript you should take a look at CanvasArray from the WebGL guys
which is effectively the same thing, exposing a chunk of raw memory to
JavaScript.  It would be nice if there was only 1 way or if the interfaces were
at least the same.  The CanvasArray ones allow access through the array operator
and can be apparently be eventually inlined in V8

http://codereview.chromium.org/234001/diff/1/9
File o3d/gpu_plugin/command_buffer.cc (right):

http://codereview.chromium.org/234001/diff/1/9#newcode27
Line 27: if (num_bytes / sizeof(int32) != size)
Maybe a comment? // check for overflow

http://codereview.chromium.org/234001/diff/1/11
File o3d/gpu_plugin/command_buffer.h (right):

http://codereview.chromium.org/234001/diff/1/11#newcode27
Line 27: PARSE_NO_ERROR,
enums are supposed to be kCamelCase now if you are renaming them might as well
make them fit the style guide.

http://codereview.chromium.org/234001/diff/1/11#newcode145
Line 145: bool error_status_;
Just a thought but what if error status was an int and was incremented on error.
Then if I was debugging I'd know how many errors happened since it last cleared.
I only bring that up because I've had it happen where it took me a while to
realize that I was looking in the wrong place in my code for an error.  I'm not
asking you to change this just bringing up the idea.

http://codereview.chromium.org/234001/diff/1/8
File o3d/gpu_plugin/command_buffer_unittest.cc (right):

http://codereview.chromium.org/234001/diff/1/8#newcode87
Line 87: EXPECT_FALSE(command_buffer_->Initialize(0x7FFFFFFF));
How about 0x40000000?

[gman, 2009-09-24 02:07:33]

I forgot

LGTM

[apatrick, 2009-09-24 19:01:06]

Yeah I'm hoping I can use the new WebGL array types. I've been talking to kbr
about supporting mapping them into the address spaces of other processes. It
seems Chromium WebGL will need this for textures and buffers and suchlike.