If a texture in a compositor frame is not allocated with Image storage (giving it a GpuMemoryBuffer), then the GLRenderer will not be able to use CALayers and will fall back to doing GL compositing which is slow.

https://bugs.chromium.org/p/chromium/issues/detail?id=786140 was about fixing this for pepper.

There are 2 places (at least) that canvas should do the same things. Maybe WebGL should be doing this to allocate textures too..?

Basically it needs to use TexStorage2DImageCHROMIUM+TexSubImage2D instead of TexImage2D. To do this it needs the viz::BufferToTextureTargetMap on RenderThreadImpl, to know what texture target (ie not GL_TEXTURE_2D) to use for the texture.

Would be nice to share this code with pepper2d.

The 2 places I know of for canvas are:

1.  OffscreenCanvasResourceProvider::SetTransferableResourceToSharedGPUContext()

This function uses TexImage2D which will land on the slow compositing path.

2. UnacceleratedStaticBitmapImage::MakeAccelerated() (called from ImageLayerBridge::PrepareTransferableResource())

This function calls SkImage::makeTextureImage() which does not have the aforementioned map to know what texture target to use, so surely does not do the good thing and will land us on the slow compositing path.

These are cases where software frames are uploaded to GL. But also when GL frames are being produced and handed to the compositor, I think they should be using the same to allocate their textures in order to land on the fast path.

AcceleratedStaticBitmapImage has a skia-generated texture inside it.

It looks like WebGL lands on the fast path. DrawingBuffer::CreateColorBuffer() uses the GpuMemoryBufferManager directly to make a GpuMemoryBuffer and an Image associated with it. But hardcodes the texture target to be GC3D_TEXTURE_RECTANGLE_ARB instead of using the map from the browser. It would be nice if this shared code with the other cases above, but not sure if it works since they don't make GpuMemoryBuffers directly. Maybe it would be simpler with the shared code method..