khushalsagar@: can you update this with your thoughts?

I think this will all fall into updating CanvasResourceProvider to stop using skia for managing canvas resources.

There are 2 sub-classes which manage gpu backed resources, CanvasResourceProviderTexture and CanvasResourceProviderTextureGpuMemoryBuffer. IIUC the GpuMemoryBuffer version still uses skia for allocating the backing texture for rendering (via SkSirface), but when it needs to be forwarded to cc for compositing, the texture is being copied into a GpuMemoryBuffer[1].

Skia internally manages recycling resources used by the SkSurface for this canvas. When this resource needs to be forwarded to cc for a frame, the SkSurface is snapshotted to produce an SkImage wrapping a GrBackendTexture. There are a few layers of wrapping now.

The SkImage is stored in an AcceleratedStaticBitmapImage which internally takes care of destroying this image on the canvas thread where it was created. It also lazily imports it into a TextureMailboxHolder that knows how to create a mailbox from this texture[2] when this mailbox needs to be sent to cc. This step also takes care of generating the sync token[3]. Finally, the AcceleratedStaticBitmapImage itself is wrapped in a CanvasResource implementation.

I think for switching to ShareableImage, we need to stop using SkSurface for allocating these textures. A lot of the hooks to be able to allocate and keep a pool of resources and get a signal for when it can be recycled are already setup and used by CanvasResourceProviderGpuMemoryBuffer. I think the ideal thing to do would be to fold CanvasResourceProviderTexture and CanvasResourceProviderGpuMemoryBuffer into a single class. IIUC, the purpose of using the GpuMemoryBuffer version is so that these resources can be overlayed, which can be done by specifying correct usage flags when creating the shareable image. The image can then be imported into skia as a GrBackendTexture to create a SkSurface backed by it.

For the copy-on-write optimization, skia basically checks for any additional refs on the snapshot SkImage whenever anyone touches the associated SkSurface to copy to a new buffer. Which can similarly be added to the CanvasResourceProvider, based on some ref-counted wrapper on a shareable image resource that we use to share the snapshot, whenever anyone tries to use its PaintCanvas.

I think other than CanvasResourceProvider/CanvasResource, the only class that should change is AcceleratedStaticBitmapImage that keeps this shareable image resource wrapper. And it can lazily import that into an SkImage if needed.

+fserb to correct anything I got wrong about canvas2d.

[1]: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/graphics/canvas_resource_provider.cc?gsn=CanvasResourceProvider&g=0&l=213
[2]:https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/graphics/gpu/graphics_context_3d_utils.cc?gsn=make_unique%3CMailboxTextureHolder%3E&g=0&l=39
[3]:https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/graphics/accelerated_static_bitmap_image.cc?gsn=GetOrCreateGpuMailbox&g=0&l=277

Oh and also, I've only looked at canvas2d details in thinking about this. I don't know how webgl works.

I think what you wrote is correct.

Maybe I'm wrong about this, but we probably still need the SkSurface as a way to get the PaintCanvas. But even then, the SkSurface can be created with a ShareableImage.

Also, you are correct about the copy-on-write. CRP would be able to do that.

Gladly, we've been adding some new perf_tests to canvas this week, which would be great to highlight perf improvements using this.

You're right, we do still need the SkSurface if canvas is using GPU raster (this won't be needed when we move to OOP), but instead of skia allocating the backing resource, we can create the SkSurface with a ShareableImage.

Re comment #3: WebGL is tracked separately.