I've been dealing with a massive performance regression in the canvas API. The frustrating bit is that they were well aware of the cost and made the change anyways. They didn't seem to stop and consider what effect it might have on major libraries and applications.
No, you are just not understanding the tradeoff. They fixed some canvas not being accelerated when they should have been. This means they can be hardware composited, drawn to and need to only exist once as a GPU texture. This is a massive win for performance and power consumption.
Here is what is not efficient, ever: getting a GPU texture into a raster format CPU accessible buffer. At best this requires synchronization and a full memory copy into a new buffer, but it can easily be much much more expensive because GPUs, and mobile GPUs basically never, store textures in raster formats. So now you need a full copy and a bunch of extra SIMD to convert it from the GPU preferred format into raster format for your getImageData call.
And all this for what is essentially a trap API! Chances are if you are calling getImageData regularly, you are doing something wrong and inefficient.
> Chances are if you are calling getImageData regularly, you are doing something wrong and inefficient.
I would love to see stats on the use cases. Personally I have never used canvas other than to getImageData in a loop!
If I only needed to draw primitives, SVG is often a better choice.
If I needed something GPU accelerated, I would switch to webgl and write shaders.
So the only thing left 2D canvas is good for is to get the pixel data to do image processing on (e.g., flood fill connected components, color histograms, etc).
Chrome 77 did waste 1 day of work for me though, I filed a bug report related to drawImage canvas-to-canvas on large files and they merged a fix for my issue pretty fast:
Interacting with googlers is horrifying. He was ready to commit to the bad decision until he was threatened with a PR disaster of breaking the software used by "hundreds of thousands of school kids".
I can't help but think that if a lowly dev like me were to report the issue the "won't fix" would've stuck.
Hundreds of people saying "My app is broken" isn't data. Someone saying "based on a search of the top Alexa 1 million sites, this will affect 8% of users" will catch their attention.
As a Chromium developer speaking based on my observations, we're also responsive to fixing bugs that affect a small percentage of sites. The difference is prioritization, and whether we'll merge fixes back to stable branches for a respin.
https://bugs.chromium.org/p/chromium/issues/detail?id=100184...