3 ms·
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 compos
by stefan_ 7y ago
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.
- throwaway_bad 7y ago> 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).