[Canvas] Rendering images using atlas vs individual elements

[Kapka]

Hello, I would like to know if there is any difference (in performenc etc.)  when using atlas over the individual images to draw on canvas. 

In code example are shown these two approaches. 

Thank you!

// Example1 - individual images
let framePointer = 0
const animationFrames = [frame, frame2, frame3,...] // images are HTMLImageElements

//rendering
ctx.drawImage(animationFrames[framePointer], 0,0)
framePointer ++


// Example2 atlas
let atlasPointer = 0
const atlas = new Image()
atlas.src = 'atlas.png'
const atlasMap = [{x,y,width,heigth},...]

//rendering
let frameInfo = atlasMap[atlasPointer]
ctx.drawImage(
atlas,                 // HTMLImageElement
frameInfo.x,           //source x       
frameInfo.y,           //source y
frameInfo.width,       //source width
frameInfo,height,      //source height
0,                     //destination x
0,                     //destination y
frameInfo.width,       //destination width
frameInfo,height,      //destination heigth
)
atlasPointer ++

 

[128p]

I'll try to do a little benchmark here, but I don't believe it does. Hopefully someone with more experience will pop up!

An obvious advantage of atlases is that you can fetch many sprites with just one request, which is inherently good.

[ivan.popelyshev]

if canvas is gpu-accelerated, you can see those operations in NVidia NView. Also, 5-6 years ago, people compared drawImage vs fillRect/pattern.

I think that it also has to be different in case your sprite is axis-aligned or not, analytical antialiasing should affect those things.

Edited October 29, 2019 by ivan.popelyshev

[Kapka]

Ok, thank you a lot ?

[b10b]

There are some extra workflow benefits of using an atlas.  These might be more tangible than modern marginal blitting performance gains?

• Separates concerns between what is a production asset (e.g. the raw png) and what is a build asset (e.g. a pngquanted atlas png representing a collection of production assets)
• Reduces file volume, repository overheads and other potentially slow directory-listing-style issues (these can be painful when dealing with thousands, or tens of thousands of frames)
• Can be faster to export from animation tooling, and easier to manage in code for technical animation (if using name based states and frame counts)
• Represents a standard of sorts, which can allows animation artists and QA to test animations in other environments or applications independent to a game which may be work-in-progress
• Reduces runtime network calls which can significantly improve loading performance for players (and therefore retention)
• Can significantly reduce runtime-memory by using best-fit heuristics (e.g. removing most of the blank spaces around individual frames, or de-duplicating frames) - which can improve runtime performance dramatically if memory is otherwise exhausted

These can add up to sizeable development and runtime performance gains.  Drawback is that there's an extra step in the workflow, and potentially another license dependency / fee.  There are some capable free tool options, and the commercial tools are usually worth their price.

For our games we don't atlas "everything", and there's plenty of reasons why balance and case-by-case decision is important.  But we do favour atlases for animation collections.