Use case
Flutter Web has adopted a rendering strategy making use of an OffscreenCanvas which acts as a WebGL surface for Skia to render to. The rendering is then displayed to the user by calling transferToImageBitmap to create a BitmapImage from the contents of the OffscreenCanvas, and then by calling transferFromImageBitmap on a bitmaprenderer canvas in the DOM, which is shown to the user. There may be more than one bitmaprenderer canvas (for example, if there are platform views in the Flutter scene which require overlay canvases), but there is only one OffscreenCanvas (and therefore only one WebGL context). Having only a single WebGL context allows Flutter Web to eliminate an entire class of bugs arising from improperly copying GL resources between more than one GL context.
Using transferToImageBitmap/transferFromImageBitmap is very fast on Chrome, since it just uses a texture saved on the GPU to transfer the rendering from the OffscreenCanvas to the bitmaprenderer canvas. However, on Firefox and Safari, calling transferToImageBitmap is significantly slower, because transferToImageBitmap incurs a very expensive call to read all of the pixels in the canvas to create the bitmap image. In practice, this made rendering using transferToImageBitmap untenable on Firefox and Safari since it caused considerable jank. So, on Firefox and Safari we have to fall back on an old (and bug-prone) rendering strategy using many WebGL-backed canvases.
Proposal
This issue tracks the bugs in Firefox and Safari, which are aware of the performance issues with transferToImageBitmap and working on addressing them.
Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1788206
Safari issue: https://bugs.webkit.org/show_bug.cgi?id=234920 and https://bugs.webkit.org/show_bug.cgi?id=267291
Once the performance issues are addressed in Firefox and Safari, we can remove the alternate multi-surface rendering strategy and keep only the OffscreenCanvas-based strategy.
Use case
Flutter Web has adopted a rendering strategy making use of an
OffscreenCanvaswhich acts as a WebGL surface for Skia to render to. The rendering is then displayed to the user by callingtransferToImageBitmapto create aBitmapImagefrom the contents of theOffscreenCanvas, and then by callingtransferFromImageBitmapon abitmaprenderercanvas in the DOM, which is shown to the user. There may be more than onebitmaprenderercanvas (for example, if there are platform views in the Flutter scene which require overlay canvases), but there is only oneOffscreenCanvas(and therefore only one WebGL context). Having only a single WebGL context allows Flutter Web to eliminate an entire class of bugs arising from improperly copying GL resources between more than one GL context.Using
transferToImageBitmap/transferFromImageBitmapis very fast on Chrome, since it just uses a texture saved on the GPU to transfer the rendering from theOffscreenCanvasto thebitmaprenderercanvas. However, on Firefox and Safari, callingtransferToImageBitmapis significantly slower, becausetransferToImageBitmapincurs a very expensive call to read all of the pixels in the canvas to create the bitmap image. In practice, this made rendering usingtransferToImageBitmapuntenable on Firefox and Safari since it caused considerable jank. So, on Firefox and Safari we have to fall back on an old (and bug-prone) rendering strategy using many WebGL-backed canvases.Proposal
This issue tracks the bugs in Firefox and Safari, which are aware of the performance issues with
transferToImageBitmapand working on addressing them.Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1788206
Safari issue: https://bugs.webkit.org/show_bug.cgi?id=234920 and https://bugs.webkit.org/show_bug.cgi?id=267291
Once the performance issues are addressed in Firefox and Safari, we can remove the alternate multi-surface rendering strategy and keep only the
OffscreenCanvas-based strategy.