Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Livecoding: canvas.drawImage Performance Is Weird but Magical

DZone's Guide to

Livecoding: canvas.drawImage Performance Is Weird but Magical

Want to put some animations in your web application? Read on to learn how to use JavaScript to implement time based physics and make your animation smooth.

· Web Dev Zone
Free Resource

Add user login and MFA to your next project in minutes. Create a free Okta developer account, drop in one of our SDKs to your application and get back to building.

This week, I had the charisma of a peeled potato. The live stream started with 6 people in the chat, and it ended with 2. Usually, it ends with … more.

So sad.

BUT! We learned stuff about canvas.drawImage, and I poked around after the stream and made this glorious thing. 14,000 smoothly animated particles! 

14,000 animated particle minions

Cool, huh? Such a shame it didn’t work during the stream. Then 3 people would’ve stayed!

The first thing we tried was the concept of sprites. Instead of doing .arc and .stroke for every particle, you do it once, then copy-paste that particle into other places like this:

// draw a sprite particle in componentDidMount
this.context.beginPath();
this.context.arc(1.5, 1.5, 1, 0, 2*Math.PI, false);
this.context.stroke();

// copy pasta particle

drawParticle(particle) {
   let { x, y } = particle;

   this.context.drawImage(this.canvas, 0, 0, 3, 3, x, y, 3, 3);
}

Using .drawImage like this tells canvas to take pixels from the top left corner and copy them to a new place. A fast operation in theory, but something went wrong for us.

Slow drawImage

Terrible. Even worse than before. Copying those few pixels thousands of times grinds our animation to a halt. With a few thousand elements, each frame render takes a few seconds.

But at least the .drawImage approach makes it easy to render arbitrary images instead of particles. Instead of using this.canvasas the source, you can use an arbitrary Image() object, which you can fill with an image from any URL on the internet.

Minion Sprites

Strange … that feels smoother, doesn’t it? I’m not going crazy, right?

Anyway, there’s only one thing left to do: decouple physics from frame rate. A big part of why the animation feels so slow is that we only calculate new particle positions once per frame, which makes sense because we’re only drawing them once per frame.

Our frame rate is not up to snuff for that. We’re dropping frames, so we have to compensate for that in our calculation. The idea is that for each drawn frame, we have to pretend like multiple physics frames happened.

Fixing physics happens in the reducer and looks like this:

// reducer

case ‘TIME_TICK’:
        let {svgWidth, svgHeight, lastFrameTime} = state,
            newFrameTime = new Date(),
            multiplier = (newFrameTime-lastFrameTime)/(1000/60); // N frames dropped

        let movedParticles = state.particles
                                  .filter((p) => {
                                      return !(p.y > svgHeight || p.x < 0 || p.x > svgWidth);
                                  })
                                  .map((p) => {
                                      let [vx, vy] = p.vector;
                                      p.x += vx*multiplier;
                                      p.y += vy*multiplier;
                                      p.vector[1] += Gravity*multiplier;
                                      return p;
                                  });

        return Object.assign({}, state, {
            particles: movedParticles,
            lastFrameTime: new Date()
        });

We start by tracking timestamps for each frame and calculating a multiplier. Then, we multiply every position and vector change with the multiplier and voilà: time-based (instead of frame-based) physics.

Time-based Physics

So smooth! I had to increase the number of particles generated on every animation tick up to 2000 just to see if anything interesting going on. Insane.

Mission accomplished, right? It’s smooth up to 8,000 particles, and we can’t push it to put more than that on-screen.

I wonder what happens if we put the minion sprite and the better physics together.

Physics Minions

Ho boy! 14,000 smoothly animated minions! 

With a production build and a big screen, you can reach over 20,000 minions on screen, and it still looks smooth. Try it.

I have no idea why it’s faster to drawImage a complex.png than a circle. Or why it’s faster to drawImage an Image() object than a part of the canvas. It makes no sense, but here we are.

Do you know?

Launch your application faster with Okta’s user management API. Register today for the free forever developer edition!

Topics:
web dev ,web application development ,animation

Published at DZone with permission of Swizec Teller, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}