to be honest, I actually don't get this change.

Blit-heavy canvas workloads suffer a lot by the decision to perform software-only rendering (justr look at the fishbowl results representative for so many canvas-based games).

There were times when browser-vendors (including mozilla) were proud to have hardware accelerated canvas - now it is disbled because of a few broken android drivers.

(In reply to Clemens Eisserer from comment #18)

to be honest, I actually don't get this change.

Blit-heavy canvas workloads suffer a lot by the decision to perform software-only rendering (justr look at the fishbowl results representative for so many canvas-based games).

There were times when browser-vendors (including mozilla) were proud to have hardware accelerated canvas - now it is disbled because of a few broken android drivers.

For blit-heavy workloads, you will get better performance, availability, flexibility, and control with WebGL. There are a number of popular JS libraries to help work with WebGL and ease the transition. This is the direction that games especially and the web in general are moving.

For other workloads, the spotty availability, instability, and security concerns are a major detractor for SkiaGL Canvas2D for various business or productivity oriented apps. Better stability and reliability are a boon there. Also, for text and filter intensive workloads, performance in software is actually better than the SkiaGL accelerated canvas (famously or infamously in CanvasMark).

Since Firefox is moving to WebRender (hopefully soon?) which isn't going to be using Skia either way, this is not a big deal really.

All Chrome-based browsers offer hw-accelerated canvas rendering, Firefox now doesn't.
This change just makes me sad, it completly throws away hw-accelerated canvas rendering, which once was a major selling point.

| For other workloads, the spotty availability, instability, and security concerns are a major detractor
| for SkiaGL Canvas2D for various business or productivity oriented apps.

What I like about canvas is, that it is guaranteed to work.
If supported, you get a hw-accelerated one, if not - you get a slower software fallback - but you can count on it to work.

With the proposed migration to WebGL, all you do, is to move the compatibility burden down to the developers.
You game does not work on card X with driver Y - not our fault - all we do is pass down your WebGL calls to the host driver.
(and, by the way, you a proposing a rewrite of all the existing, performance sensitive canvas games/applications)

Please test gfx.canvas.accelerated (bug 1741501), it seems to be similar to https://github.com/jagenjo/Canvas2DtoWebGL.
Hopefully Mozilla can replace CPU canvas (skia) and GPU canvas with some Rust implementations at some point.

IIUC, it's hard to gpu-accelerate the Canvas API, developers should rather demand a software fallback for WebGL.
(Chromium seems to have replaced old SwiftShader (GL) with GL-to-Vulkan ANGLE on top of the new SwiftShader (Vulkan).)