Kapka Posted October 29, 2019 Share Posted October 29, 2019 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 ++ Quote Link to comment Share on other sites More sharing options...
128p Posted October 29, 2019 Share Posted October 29, 2019 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. Kapka 1 Quote Link to comment Share on other sites More sharing options...
ivan.popelyshev Posted October 29, 2019 Share Posted October 29, 2019 (edited) 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 128p and Kapka 2 Quote Link to comment Share on other sites More sharing options...
Kapka Posted October 29, 2019 Author Share Posted October 29, 2019 Ok, thank you a lot ? Quote Link to comment Share on other sites More sharing options...
b10b Posted October 29, 2019 Share Posted October 29, 2019 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. Kapka 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.