There are lots of classes that use ImageBuffer(Surface) and so this task needs to be done bits by bits.
First and foremost, there are a lot of use cases when Canvas2DLayerBridge diverts a command to HTMLCanvasElement via ImageBuffer (note, HTMLCanvasElement is a client of ImageBuffer); this use of ImageBuffer as a layer can be removed if we introduce a reference from Canvas2DLayerBridge to HTMLCanvasElement. We can start from this.
A couple of other easily identifiable pieces are:
1. GPU memory management can be shifted to HTMLCanvasElement
2. The use of Skia encoders in ImageDataBuffer struct can be moved to third_party/WebKit/Source/platform/image-encoders/ImageEncoder.h
3. ImageBuffer is used trivially in OffscreenCanvas; it's just there for OffscreenCanvas to access to the ImageBufferSurface.
and so on...
In general, I think
1. Things that are specific to accelerated html canvas can be shifted to Canvas2DLayerBridge and HTMLCanvasElement.
2. Codes in the ImageBufferSurface and its subclasses can be moved to CanvasResourceProvider, a class that needs to be extended beyond the current use in Canvas2DLayerBridge.
Current class diagram v.s. desired class diagram (draft)
After taking away ImageBuffer, CanvasRenderingContext (or BaseRenderingContext2D, less preferably) should have a way to access CanvasResourceProvider as there are many actions that are directly acting on the graphics resource.
Diagrams lgtm. Just one detail though I think it would be nice to have a single point of ownership for CanvasResourceProvider. That could be CanvasRenderingContextHost.
Comment 1 by xlai@chromium.org
, Oct 20 2017