Bug 1717297 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
Testing different WebGL demos on https://webglsamples.org/ on Wayland with compositor integration reveals that we currently almost never make WebGL canvases opaque, effectively doubling the blitting bandwidth required in a (system) compositor.

This may be a bug in the sites code, however almost every WebGL canvas I encounter gets composited as not-opaque. It would be great if we could somehow detect cases where we can make the canvas opaque.
Revision 1 by
on 
Testing different WebGL demos on https://webglsamples.org/ on Wayland with compositor integration reveals that we currently almost never make WebGL canvases opaque, effectively doubling the blitting bandwidth required in a (system) compositor.

This may be a bug in the sites code, however almost every WebGL canvas I encounter gets composited as not-opaque. It would be great if we could somehow detect cases where we can make the canvas opaque. This should improve performance on all internal or external compositors.
Revision 2 by
on 
Testing different WebGL demos on https://webglsamples.org/ on Wayland with compositor integration reveals that we currently almost never make WebGL canvases opaque, effectively doubling the blitting bandwidth required in a (system) compositor.

This may be a bug in the sites code, however almost every WebGL canvas I encounter gets composited as not-opaque. It would be great if we could somehow detect cases where we can make the canvas opaque. This should improve performance on all internal or external compositors.

P.S.: to test this on Linux bug 1716044 is required

Back to Bug 1717297 Comment 0