Sign in to follow this  
sauliusg

SpriteSheet as memory saver?

Recommended Posts

As we all know it's not easy to have all textures in power of two size. So a lot of memory is wasted when such textures are loaded into memory. Atlases helps with that, because it optimally packs all textures into texture of power of two size. In our case we could easily save 30% of memory.

 

I'm wondering is there any way to reduce memory footprint using texture altases in pixi.js? Texture packages are produced with TexturePacker ( https://www.codeandweb.com/texturepacker ) and loaded following this pixi tutorial ( https://github.com/GoodBoyDigital/pixi.js/tree/master/examples/example%202%20-%20SpriteSheet ). The main problem is that creating PIXI.Sprite object with texture from atlas increases memory usage twice, because looks like it creates texture cache for sprite. I'm wondering maybe there is some way to eliminate texture cache and make PIXI.Sprite object just a metadata that defines rectangle in the atlas instead of copying texture rectangle from atlas to texture cache?

Share this post


Link to post
Share on other sites

Xerver, thanks a lot for your response. 

 

That's very interesting why we experience twice increased memory usage when we use atlases. Our experience is that if we load 2048x2048 atlas to memory, then memory increases about 16MB. Next when we start to render multiple sprites created from this atlas, then memory increases more than 16MB again. So instead of total 16MB increase we get more than 32MB total increase. And then our game crashes on low memory devices, because we have 7 such atlases. My understanding was that sprite caches it's texture when sprite is created using that atlas, so that's where double memory usage happens.

 

So you are saying that atlas is loaded once into memory and sprites that are created from this atlas doesn't copy image to cache, instead it points to atlas and dynamically copies sprite texture from atlas on demand? Then I'm a bit confused with this - "Textures are cached", because cache by definition should be duplicate. 

 

Is it possible that there is some glitch because we run our game on Windows Phone 8.1 built as Windows Store App? 

Share this post


Link to post
Share on other sites

 because cache by definition should be duplicate. 

 

No it isn't, it means a reference to an object is kept and not destroyed.

 

The memory usage you are seeing depends on how you use the textures and do different draws. In WebGL the entire atlas is sent to the GPU and sprites sharing that atlas are batched together and drawn in a single call, the image isn't duplicated in heap. On canvas, each texture is draw separately using `drawImage` calls on *the same atlas* so we don't duplicate it in JS heap there either. The source object in PIXI.TextureCache and the source object of sprite's textures is the same (assuming they use the same atlas) just two different references to the same object.

 

A PIXI.Texture is a base image source (usually an Image or Canvas object), and a PIXI.Rectangle that defines the area of the source this texture represents. We don't duplicate the source image we just have references to it in a couple places. Without seeing your code and/or profiling dumps there isn't really a way for me to see what you mean. 16MB is generally the "max" size you can send to a WebGL context, perhaps that is causing some issues.

Share this post


Link to post
Share on other sites

Xerver, thanks again for your response. We use Canvas.

 

We tried to do isolated example, but we're not able to reproduce double memory consumption. But it still uses significantly more memory than we expect and could be related to that double memory increase in our game. Memory usage graph - https://drive.google.com/file/d/0B-fFqmsxvtePdXBnVDRMWWlJVG8/edit?usp=sharing . There is initial memory jump - WP8.1 app overhead is about 15MB. Then interesting thing happens - memory increases by 35MB more when we create 6 Atlases (2048x2048 size each). Then we start to render all sprites from first atlas, second atlas and so on. Looks like atlases are loaded into memory correctly (each atlas loading takes about 16-20MB) when corresponding sprites are rendered. At the end app takes about 160MB. So question is why there is 35MB memory increase when atlases are created even before any sprites are loaded?

 

VS app is here https://drive.google.com/file/d/0B-fFqmsxvtePTG9xdjI5M0l6Qzg/edit?usp=sharing , which contains all JS, images etc.

Share this post


Link to post
Share on other sites

Trying to get my PC updated to Win 8.1 (won't let me run it till I upgrade) but encountering some issues, sorry for the delay!

 

Only thing I want to see now is a heap snapshot when you have that large memory usage. That should tell you exactly what is causing the large memory usage.

Share this post


Link to post
Share on other sites

Xerver, it's probably not Pixi.js problem, because heap difference before and after atlases creation doesn't show anything significant. Only total used memory by app shows memory increase. The only one thing I suspect is that WP8.1 itself reads those image files into memory (actually that memory increase is around total size of these images) so it can serve it for JS engine on demand.

 

Have you got chance to profile the app? Maybe you findings were different?

Share this post


Link to post
Share on other sites

No i haven't (sorry, no windows 8.1) but that may make sense. If you are only seeing it happen on that platform, then most likely the environment itself has them in memory of the app, and then in the JS heap when you load them. A heap snapshot should be able to tell you exactly what pixi.js has loaded.

 

Let me know if there is anything else I can help with.

Share this post


Link to post
Share on other sites

I encourage you to install Chrome/Firefox extension called 'WebGL Inspector' and check 'Textures' tab to see if you don't have any extra/unnecessary outcome ( for example from bad usage of cacheAsBitmap which generates and do not destroy textures at runtime automatically ).

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.