Canvas Best Practices (Performance)

As mentioned earlier, we were left with only 16ms to render each frame. However, all we are really doing is steps 1 and 2.1 above, and step 2.2 is done by the browser in a different thread (at least that is the case with almost all modern browsers). The real premise for smooth animation is that all of the above work is done in 16ms, so the time consumed at the JavaScript level is best kept under 10ms.

Although we know that, in general, rendering is much more expensive than computation (3~4 orders of magnitude). Unless we use some time-intensive algorithm (which is discussed in the last section of this article), there is no need to delve into the optimization of the computation.

What we need to explore is how to optimize rendering performance. The general idea of optimizing rendering performance is very simple, which can be summarized as follows:

1. Minimize the number of calls to render related apis per frame (usually at the expense of computational complexity).
2. In each frame, the API with the lowest rendering overhead is called whenever possible.
3. Within each frame, the rendering API is called in a way that “results in low rendering overhead” whenever possible.

At this point, it doesn’t seem to have anything to do with performance. I’m going to tell you now how you feel about the overhead of assigning to context.lineWidth being much higher than the overhead of assigning to a normal object.

Of course, it’s easy to understand. The Canvas context is not a normal object. When you call context.lineWidth = 5, the browser needs to do something immediately so that the next time you call an API like Stroke or strokeRect, The lines drawn are exactly 5 pixels wide (which is also an optimization, as you can imagine, because otherwise these things would have to wait until the next stroke and affect performance even more).

I tried the following assignment 106 times, and the result was that it only took 3ms to assign an attribute to a normal object and 40ms to assign an attribute to the context. It is worth noting that if you assign an invalid value, the browser takes some extra time to process the invalid input, as shown in the third/fourth case, which takes 140ms or more.

somePlainObject.lineWidth = 5; // 3ms (10^6 times) context.lineWidth = 5; // 40ms context.lineWidth = 'Hello World! '; // 140ms context.lineWidth = {}; // 600msCopy the code

For context, the assignment overhead for different properties is also different. LineWidth is just one of the less expensive types. The overhead of assigning to some of the other attributes of the context is summarized below.

The overhead of changing the context state is relatively small compared to the actual drawing operation, since we haven’t actually started drawing yet. We need to understand that changing the properties of the context is not completely free. We can reduce the frequency of context state changes by properly arranging the order in which drawing apis are called.

The starting point of layered Canvas is that each element (layer) in the animation has different requirements for rendering and animation. For many games, the frequency and magnitude of the main characters’ changes is large (they’re usually walking around and killing each other), while the frequency or magnitude of the background changes is relatively small (basically constant, slowly changing, or only occasionally changing). Obviously, we need to update and redraw people quite frequently, but for backgrounds we might only need to paint once, maybe every 200ms, definitely not every 16ms.

For Canvas, the ability to keep different redraw frequencies on each Canvas is the biggest benefit. However, hierarchical thinking solves much more than that.

The layered Canvas is also easy to use. All we need to do is generate multiple Canvas instances and place them on top of each other. Each Canvas uses a different Z-index to define the stacking order. Then redraw the layer only when it needs to be drawn (perhaps “never”).

var contextBackground = canvasBackground.getContext('2d');
var contextForeground = canvasForeground.getContext('2d');

function render(){
  drawForeground(contextForeground);
  if(needUpdateBackground){
    drawBackground(contextBackground);
  }
  requestAnimationFrame(render);
}Copy the code

Remember, the content on the top Canvas overwrites the content on the bottom Canvas.

Sometimes, Canvas is just a “window” of the game world. If we draw the whole world in every frame, there will be a lot of things drawn outside the Canvas. Drawing API is also called, but it has no effect. We know that determining whether an object is in the Canvas involves additional computational overhead (such as inverting the global model matrix of a game character to factor out the object’s world coordinates, which is not a particularly cheap overhead) and increases the complexity of the code, so the question is, is it worth it?

I did an experiment and drew a 320×180 image 104 times. When I drew inside the Canvas each time, it took 40ms, while when I drew outside the Canvas each time, it only took 8ms. Think about it, and considering that the overhead of computation is two or three orders of magnitude different from the overhead of drawing, I think it’s still necessary to filter out what objects are outside the canvas through computation.

“Blocking” can be understood as JavaScript code that runs continuously for more than 16ms, and JavaScript code that “causes the browser to take more than 16ms to process.” Even on a non-animated page, blocking is immediately apparent to the user: blocking makes objects on the page unresponsive — buttons can’t be pressed, links can’t be opened, tabs can’t even be closed. On pages with a lot of JavaScript animation, blocking will stop the animation for a while, and not resume execution until the blocking is restored. If there are frequent “minor” blocks (such as these optimizations mentioned above that take more than 16ms to render a frame), then “frame loss” will occur.

CSS3 Transition and Animate are not affected by JavaScript blocking, but are not the focus of this article.

Review images

Occasional and small blocks are acceptable, frequent or large blocks are not. In other words, we need to solve two types of blocking:

• Frequent (usually minor) blocking. The main reason for this is the high rendering performance overhead, with too many things to do in each frame.
• Large (though occasionally) blockages. The main reasons are running complex algorithms, large-scale DOM operations, and so on.

For the former, we should carefully optimize the code, sometimes making the animation less complex (and cool), as the optimization solution in the previous sections of this article addresses.

For the latter, there are mainly the following two optimization strategies.

• Using the Web Worker, perform the calculation in another thread.
• The task is divided into several smaller tasks and inserted into multiple frames.

Web Workers are great things, with good performance and good compatibility. The browser uses another thread to run the JavaScript code in the Worker without blocking the main thread at all. Animations (especially games) inevitably have some algorithms with high time complexity, and Web workers are perfect for running them.

Review images

However, the Web Worker cannot manipulate the DOM. So, sometimes we use another strategy to optimize performance, which is to break tasks into smaller tasks and insert them into each frame. While doing so would almost certainly make the total time to execute the task longer, at least the animation wouldn’t get stuck.

Review images

Looking at the Demo below, our animation moves a red div to the right. This is done in the Demo by changing its transform property every frame (the same goes for Canvas drawing).

I then created a task that would block the browser: get the average of 4×106 math.random (). Click the button and the task is executed, with the results printed on the screen.

Review images

As you can see, if you perform this task directly, the animation will “freeze” significantly. Using a Web Worker or splitting tasks does not stall.

The above two optimization strategies have the same premise, that is, the task is asynchronous. That is, when you decide to start a task, you don’t need to know the outcome immediately (in the next frame). For example, even if a user action in a strategy game triggers a pathfinding algorithm, you can wait a few frames without the user knowing it before moving your game character. In addition, splitting tasks to optimize performance introduces a significant increase in code complexity, as well as additional overhead. Sometimes I think it might be a good idea to prioritise slashing requirements.