Jump to content

[Canvas] Rendering images using atlas vs individual elements


Kapka
 Share

Recommended Posts

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 ++

 

Link to comment
Share on other sites

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 by ivan.popelyshev
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...