WebGL VS Canvas 2D hardware acceleration

These days I need to draw a lot of images on canvas. The canvas size is 800x600px, and I have many 256x256px images (some smaller) to draw on it, these small images will make up the full image on the canvas. I have two ways to implement this.

First, if I use a canvas 2D context, that is context = canvas.getContext('2d') , then I can just use the context.drawimage() method to put each image in the correct canvas location.

In another way, I use WebGL to draw these images on canvas. Thus, for each small image I need to draw a rectangle. The size of the rectangle is the same as that of this small image. In addition, the rectangle is in the right place on the canvas. Then I use the image as a texture to fill it.

Then I compare the performance of these two methods. Both of their fps will reach 60, and the animation (when I click or move the mouse, the canvas will be redrawn many times) looks very smooth. Therefore, I compare their CPU usage . I expect that when I use WebGL, the processor will use less because the GPU will provide a lot of drawing work. But as a result, the use of the CPU looks almost the same. I am trying to optimize my WebGL code, and I think it is good enough. Google, I discovered that a browser, such as Chrome, Firefox, will enable Hardware Acceleration by default. Therefore, I am trying to close hardware acceleration. Then the CPU usage of the first method becomes much higher. So my question is, since canvas 2D uses the GPU for acceleration, do I need to use WebGL only for 2D rendering? What is the difference between 2D GPU acceleration and WebGL? They both use a graphics processor. Maybe there is some other way to reduce the CPU usage of the second method? Any answer would be appreciated!

+6
source share
1 answer

Canvas 2D is still supported in more places than WebGL, so if you don’t need any other functionality, working with Canvas 2D will mean that your page will work on browsers that have canvas but not WebGL (for example , old Android devices). Of course, it will be slow on these devices and may fail for other reasons, such as running out of memory if you have a lot of images.

Theoretically, WebGL could be faster because the default value for canvas 2d is that the image file is saved, but for WebGL it is not. This means that if you turn off anti-aliasing in WebGL, the browser has the ability to double the buffer. Something he cannot do with canvas2d. Another optimization is that in WebGL you can turn off alpha, which means that the browser has the ability to turn off blending when composing your WebGL with a page, again that it has no way to do with 2d canvas. (there are plans to disable alpha for 2d canvas, but as of 2017/6 it is not widespread)

But by option, I mean just that. It is up to the browser to decide whether to make these optimizations.

Otherwise, if you did not select these optimizations, perhaps 2 will be the same speed. I personally have not found this. I tried to draw a few drawImage with only 2d canvas and did not get a smooth frame rate, as it did with WebGL. It was pointless, but I assumed that something was happening inside the browser, and I was not aware.

I think this sums up. WebGL is low level and well known. The browser cannot do to ruin it. Or, in other words, you are 100% in control of the situation.

With Canvas2D, on the other hand, it is in the browser what to do and what optimizations to do. They can be changed in each release. I know that at some point, any canvas under 256x256 was not hardware acceleration. Another example is what the canvas does when drawing an image. In WebGL, you create a texture. You decide how complex your shaders are. In Canvas, you have no idea what it is doing. Perhaps it uses a sophisticated shader that supports all the various globalCompositeOperation canvases, masking and other functions. Perhaps, to manage memory, he breaks the images into cartridges and makes them into pieces. For each browser, as well as for each version of the same browser, what it decides to do depends on this command, where, like with WebGL, it is almost 100% up to you. There is not much that they can do in the middle to ruin WebGL.

FYI: Here's an article describing how to write a version of the canvas2d drawImage WebGL function , and then an article on how to implement the canvas2d matrix stack .

+10
source

All Articles