Currently when texture_from_pixmap is supported, SurfaceBufferOGL, which uses ThebesLayerBuffer::BeginPaint, is used for the ThebesLayerBufferOGL. This doesn't support component alpha. It looks like BasicBufferOGL, which does support component alpha, could be used even with texture_from_pixmap, if blitting of the buffer is handled correctly. This might involve glXWaitGL/glFinish after BlitTextureImage(), or perhaps a surface MovePixels.

I've even run some reftests (layout/canvas, layout/scrolling, layout/layers) and used the browser for some time. Looks like glXWaitGL/glFinish isn't needed.

Comment on attachment 657906 [details] [diff] [review] WIP GLContextGLX::CreateTextureImage also uses this function, so we can't just remove it. (You should be getting slower performance of native widget and plugin drawing, and canvas.)

BlitTextureImage will call BindTexture on the source for the blit, which flushes/finishes the X drawing that happened on the source. I guess a glXWaitGL is not absolutely necessary before the immediate X drawing as that is performed on a different region of the new buffer than the GL blit. However, we need to know that the blit finishes before subsequent invalidation means more X drawing, which may be to the same region as the blit destination. The GL drawing is probably usually going to happen before X drawing, but may not, especially in cases where the driver uses a separate thread for gpu command dispatch. Some gl commands will implicitly glFlush. glFlush may be sufficient - I don't know - but I haven't discovered any guaranteed flushes that will happen before the next X drawing. This double synchronization is making me think that an XCopyArea or gfxContext copy may be preferable to using GL for these TextureImageGLXs. That might be most easily implemented by making BlitTextureImage virtual and overriding in TextureImageGLX.

I don't see why the LOCAL_GL_TEXTURE_2D path in BasicBufferOGL::BeginPaint needs to Resize the destBuffer (which has already been created that size), nor why the non-LOCAL_GL_TEXTURE_2D needs to recreate the destBuffer after it has just been created. Nor do I see why the non-LOCAL_GL_TEXTURE_2D path doesn't adjust result.mRegionToDraw

(In reply to Karl Tomlinson (:karlt) from comment #3) > Some gl commands will implicitly glFlush. glFlush may be sufficient - I > don't know - but I haven't discovered any guaranteed flushes that will happen > before the next X drawing. http://www.opengl.org/wiki/Synchronization says "The purpose of glFlush is to tell OpenGL to sit there and wait until all commands have been added to the GPU's command queue." That sounds sufficient, unless there are multiple command queues. So my guess is an implicit glFlush is likely sufficient, but if we add an explicit flush, the glWaitX would be the proper method to use.

(In reply to Karl Tomlinson (:karlt) from comment #5) > if we add an explicit flush, then glXWaitGL is the proper method (I mean). But I think an X-based TextureImageGLX::BlitTextureImage would better separate X and GL phases of drawing/compositing, reducing required syncs.

With XRender gone, pixmaps aren't used anymore, right? I think this can be closed.