Sign in to follow this  
Kapka

[Canvas] Rendering images using atlas vs individual elements

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

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.