Properly advertise GL_CHROMIUM_copy_texture_to_parent_texture extension....

Advertise the GL_CHROMIUM_copy_texture_to_parent_texture and
GL_CHROMIUM_map_sub extensions by default. These are needed in
WebGraphicsContext3D instances in support of the accelerated 2D canvas
and video rendering functionality.

Associated WebKit bug is https://bugs.webkit.org/show_bug.cgi?id=46894 .
Tested on Linux with this refactoring, accelerated 2D canvas, and
HTML5 video.

BUG=none
TEST=none


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

[Ken Russell (switch to Gerrit), 2010-11-03 01:59:13]

Please review, thanks. I'm not sure whether this is the preferred way to get
these extensions exposed to WebKit or whether the intent was that code in WebKit
would explicitly enable these extensions at run time. We don't have the APIs
plumbed through yet to allow WebKit code to turn on extensions at run time, and
I'm currently in the process of changing how OpenGL extensions are exposed to
WebKit, so if that is necessary hopefully we can defer that to a subsequent CL.

[greggman, 2010-11-03 02:56:17]

Just checking:

This will work but webgraphicscontext3d_command_buffer_impl.cc handles the WebGL
path only right? What does WebGL need with these extensions? The Compositor, The
Canvas2D, etc all go through a different path AFAIK.

Issues: MapSubTexImage2D and MapBufferSubData are memory hogs. It works for
video because video makes 1 context per video and one size of video but WebGL,
if using MapXXX will use different sizes depending on user requests.

There was some talk of adding another mapping extension and giving the client
direct control of shared memory lifetime. That would let the client not use too
much memory but it would have the issue that it would slow down mapping a bunch
more since allocating and freeing shared memory is a synchronous operation.

It seems like for now, just using glBufferSubData and glTexSubImage2D are the
way to  go. No?

Otherwise, I could try to limit the memory usage of glMapXXX by limiting it to 2
or 3 shared memory regions. That might help some. The issue right now is if you
do glMapTexSubImage2D(4meg image) then, glMapTexSubImage2D(5meg image) then
glMapTexSubImage2D(6meg image) it currently has 4+5+6 = 15meg of shared memory
allocated. It never frees because the freeing and allocating are expensive and
the use case was video where the size requested is always the same.  The problem
with freeing is 3 fold. One, there's no fast way for the client to know when
it's safe to free since usage of the shared memory by the service is async. The
best I can do is set some flag in the client side library that says
"if_there_are_outstanding_allocations_see_if_they_have_completed_and_if_so_free_them"
after ever GL command or after every sync of the put/get pointers.

but even if I do that, I don't actually want to free them because that means
next time someone does a map I have to reallocate. Reallocate is really
expensive and would defeat the purpose of using MapXXX in the first place.

Finally, even if the next MapXXX is the same size, if the a previous buffer is
still in use I need to allocate a new buffer. That's the video case. I expect
video can get 3 buffers going.  If that's the case I have to keep 3 buffers
around to keep the speed up for video so that means the the 4+5+6 case above
would still exist.

Next up, GL_CHROMIUM_copy_texture_to_parent_texture is only used by canvas2d and
is already exposed (no string though). It doesn't seem like WebGL should be
using that feature. If it is, then their's no point in having the fake FBO based
backbuffer per context. Copy texture to parent exists only to allow canvas not
to use the FBO based backbuffer. If WebGL is not going to use it either there's
not much point in having it.

So, I just want to clarify the desired usage.

[Ken Russell (switch to Gerrit), 2010-11-03 18:10:47]

On 2010/11/03 02:56:17, greggman wrote:
> Just checking:
> 
> This will work but webgraphicscontext3d_command_buffer_impl.cc handles the
WebGL
> path only right? What does WebGL need with these extensions? The Compositor,
The
> Canvas2D, etc all go through a different path AFAIK.

This used to be the case, but no longer is. In order to most easily enable
testing for the compositor and accelerated 2D canvas, the compositor, 2D canvas,
and video rendering were all recently refactored to use GraphicsContext3D to
perform their drawing. GC3D uses the WebGraphicsContext3DCommandBufferImpl when
running inside of Chromium and a different, in-process implementation when
running in the testing harness.

Therefore the extensions that are needed by the accelerated 2D canvas
(GL_CHROMIUM_copy_texture_to_parent_texture) as well as video rendering
(GL_CHROMIUM_map_sub) need to be available. I am in the process of refactoring
how extensions are handled in GC3D in WebKit, and it is now required that the
available extensions show up in the extensions string.

[greggman, 2010-11-03 18:56:42]

On Wed, Nov 3, 2010 at 11:10 AM, <kbr@chromium.org> wrote:

> On 2010/11/03 02:56:17, greggman wrote:
>
>> Just checking:
>>
>
>  This will work but webgraphicscontext3d_command_buffer_impl.cc handles the
>>
> WebGL
>
>> path only right? What does WebGL need with these extensions? The
>> Compositor,
>>
> The
>
>> Canvas2D, etc all go through a different path AFAIK.
>>
>
> This used to be the case, but no longer is. In order to most easily enable
> testing for the compositor and accelerated 2D canvas, the compositor, 2D
> canvas,
> and video rendering were all recently refactored to use GraphicsContext3D
> to
> perform their drawing. GC3D uses the WebGraphicsContext3DCommandBufferImpl
> when
> running inside of Chromium and a different, in-process implementation when
> running in the testing harness.
>
> Therefore the extensions that are needed by the accelerated 2D canvas
> (GL_CHROMIUM_copy_texture_to_parent_texture) as well as video rendering
> (GL_CHROMIUM_map_sub) need to be available. I am in the process of
> refactoring
> how extensions are handled in GC3D in WebKit, and it is now required that
> the
> available extensions show up in the extensions string.


The way it should work is it should pass "*" for the extensions except in
the WebGL case.

So you need to refactor WebGraphicsContext3DCommandBuffer so you can pass in
whether the user is WebGL or something else.

In the non-WebGL case all extensions should be on by default.


>
>
>
> http://codereview.chromium.org/4268004/show
>

[Ken Russell (switch to Gerrit), 2010-11-03 20:05:08]

On 2010/11/03 18:56:42, greggman wrote:
> On Wed, Nov 3, 2010 at 11:10 AM, <mailto:kbr@chromium.org> wrote:
> 
> > On 2010/11/03 02:56:17, greggman wrote:
> >
> >> Just checking:
> >>
> >
> >  This will work but webgraphicscontext3d_command_buffer_impl.cc handles the
> >>
> > WebGL
> >
> >> path only right? What does WebGL need with these extensions? The
> >> Compositor,
> >>
> > The
> >
> >> Canvas2D, etc all go through a different path AFAIK.
> >>
> >
> > This used to be the case, but no longer is. In order to most easily enable
> > testing for the compositor and accelerated 2D canvas, the compositor, 2D
> > canvas,
> > and video rendering were all recently refactored to use GraphicsContext3D
> > to
> > perform their drawing. GC3D uses the WebGraphicsContext3DCommandBufferImpl
> > when
> > running inside of Chromium and a different, in-process implementation when
> > running in the testing harness.
> >
> > Therefore the extensions that are needed by the accelerated 2D canvas
> > (GL_CHROMIUM_copy_texture_to_parent_texture) as well as video rendering
> > (GL_CHROMIUM_map_sub) need to be available. I am in the process of
> > refactoring
> > how extensions are handled in GC3D in WebKit, and it is now required that
> > the
> > available extensions show up in the extensions string.
> 
> 
> The way it should work is it should pass "*" for the extensions except in
> the WebGL case.
> 
> So you need to refactor WebGraphicsContext3DCommandBuffer so you can pass in
> whether the user is WebGL or something else.
> 
> In the non-WebGL case all extensions should be on by default.

OK. I can do that refactoring, but it will take some time. The extension
refactoring I'm doing upstream in WebKit should make it easier to distinguish
between the WebGL and non-WebGL cases. However, in order to land that extension
refactoring I must have these extension strings visible, so let's get this
change in and I'll file a follow-on bug.

> 
> >
> >
> >
> > http://codereview.chromium.org/4268004/show
> >
>

[greggman, 2010-11-03 20:06:48]

ok, LGTM