Canvases and timers
Recently, I have discovered a site that uses multiple canvas elements on a page to animate different behaviors. The animations started as soon as I have scrolled to the corresponding canvas element, and the more I scrolled, the more animations were started. Of course, most of them remained off screen, but I could still feel their effect on the scrolling experience. It was interesting to me why this happened, because the canvas element in itself allows for very fast and smooth animations and requestAnimationFrame proves it. So I opened Chrome Developer Tools and recorded what was happening. When I went to the memory tab, I saw the following sawtooth pattern:
During the animations, memory usage increased slowly, but steadily while I was doing absolutely nothing. When it reached 21.1MB I stopped the recording, because it was clear what would happen. This could be one reason why the site slowed down the longer I stayed on it.
Here are the individual frames:
I have expanded two of the bars to see more clearly what is happening. They both have shown that a timer is fired repeatedly on line 3917 in the file processing.js. These timers collectively add a lot of computational overhead and slowed down the animations in the canvas elements. The more elements we have, the more cautious we need to be with how efficiently these animations are performed as this example illustrates. RequestAnimationFrame can be used instead of timers here.
As we can see, it is not the canvas element that is the problem, but rather how we use it. Even given a good technology, we may still misuse it. Checking how our creations respond in use allows us to see problem areas before they reach the user.