Saved offscreen textures are allocated GL_RGB when no alpha channel is reques...

Saved offscreen textures are allocated GL_RGB when no alpha channel is requested.

There appears to also be problems in ANGLE which have not been addressed yet, specifically GL_RGB textures are allocated D3DFMT_A8R8G8B8 instead of D3DFMT_X8R8G8B8.

Prevent saved and target offscreen resources from being destroyed if we don't have a context.

TEST=try, run demos locally
BUG=61441
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=64940

[greggman, 2010-11-03 01:52:30]

lgtm

[greggman, 2010-11-03 02:55:06]

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.

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

Ignore that last message. It was meant for another CL :-(