Bug 218179

Summary: Make GraphicsContextGL draw to ImageBuffer
Product: WebKit Reporter: Kimmo Kinnunen <kkinnunen>
Component: WebGLAssignee: Kimmo Kinnunen <kkinnunen>
Status: ASSIGNED ---    
Severity: Normal CC: dino, jonlee, simon.fraser, thorton, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Local Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=217211

Description Kimmo Kinnunen 2020-10-26 06:00:05 PDT
Make GraphicsContextGL draw to ImageBuffer

Current ownership for WebGL canvas is roughly:

HTMLCanvasElement -> WebGLRenderingContextBase -> GraphicsContextGL -> WebGLLayer

Current ownership for 2D canvas is roughly:

HTMLCanvasElement -> CanvasBase -> ImageBuffer -> context 

This discrepancy is probably not warranted solely by the difference wrt 2D painting to document vs. WebGL "rendering to ac layer".

There appears to be a lot of confusion because WebGL does not have a concept of a HTMLCanvasElement -level manipulatable drawing buffer and display buffer.

Instead, when HTMLCanvasElement needs WebGL contents to its ImageBuffer, there is all sorts of hoops to be jumped and the code itself ends up buggy and suboptimal.

Current:
* clear logic is buggy
* print / snapshot logic is buggy
* Element::toDataURL logic is buggy
* There's disproportionally high complexity and low quality implementation of reading back the WebGL canvas for above

In addition, the webgl abstraction is wrong way around in order to do logical "remote webgl". 

The abstraction should/could be:
- HTMLCanvasElement -> ImageBuffer 
- Create GraphicsContextGL that draws to this ImageBuffer
- Create WebGLLayer (e.g. IOSurfaceLayer) that receives snapshots of the ImageBuffer during preparing the drawing buffer as display buffer
- HTMLCanvasElement (et al) would operate mostly on the ImageBuffer, not large number of "if (is<WebGLRenderingContextBase>)" type code.
Comment 1 Radar WebKit Bug Importer 2020-11-02 05:01:14 PST
<rdar://problem/70946153>