How To: Audit Image RAM

[Sigmag]

What I aim to do with this blog post is set people on the right path from the get go with how image size in RAM works. I also want to provide others with the system I used to audit my image RAM and process I used to cut out inefficiencies.

 

This should help you to get a good visual overview of which of your images are wasting the most RAM and where you can cut the fat. 

 

You can plug in the image asset list from your exported project and the sheet will give you some nice color coded information that isn't too hard on the eyes.

 

 

Just click the banner above or, you can click this link too: http://pangolingames.com/how-to-audit-image-ram/

 

There is a RAM vs Storage overview before it gets to the utility itself, that should hopefully help explain how image download size and image size in RAM are not the same thing.

 

In any case, I hope you find it an enjoyable and enlightening read! If you find anything that's incorrect, let me know!

 

[Gio]

It's a nice post and mostly accurate, but I don't entirely agree with the power-of-2 thing.

 

That depends on the implementation and I think most browsers these days internally create "pages" that are a large power-of-2 size (like 4096x4096 but it depends on the platform), then as they load and decode images they store them in these pages where they can find some free space. So having textures that are not power-of-2 shouldn't be a big deal in terms of memory usage in many cases - actual memory usage is a lot closer to (width * size * 4) on average, if you have a good number of differently-sized textures. Having said that, power-of-2 textures will always be more optimal for memory.

 

But in general, should you try to make all your textures power-of-2? I think definitely not (unless you're desperate on the memory side). What kills performance, in many real-life cases with html5, is fill rate (how many pixels you draw) and, depending on the browser, filtering operations (how aggressively you resize images, especially in Chrome).

 

Extreme example:  If you have an image that is 257x257, rounding it up to 512x512 to make a better use of your RAM and scaling it down when you need to draw it (or surrounding the actual image with transparent pixels) may be a terrible idea - much better to stick with 257x257.

 

Anyway, it always depends on your particular scenario.

 

Overall it's a good informative post

[Sigmag]

Thanks for reading through! The practices in this post are more fruitful for those developers on mobile vs PC where RAM is much scarcer and performance is much more affected.

 

I'm still solidifying my understanding of everything as well, so I'm glad you mentioned the 'paging' done by browsers! We had worked with application wrappers that don't use the paging system too, so it's like you said - it always depends on your particular scenario/environment. Especially on mobile where the page sizes would be smaller, which would make it easier to create extra pages with odd image dimensions.

 

As for if you should try to make all of your textures power of two... I think yes, but not for only the sake of RAM. It's like you said, it will not matter in all situations, but it will help to account for all situations, and a huge reason I stick to the power of two image size in textures is because it helps in the manipulation of the image file as well. If I wanted to resize a 257x257 to 50% (turn 4px into 1), it would need to resize to 128.5x128.5 which doesnt exist, so it would round - causing pixel information to shift and blur on resample. By keeping in line with power of two image sizes, you can maintain image integrity, when you reisize a 256x256 image to 128x128 it will turn 4 pixels into 1, allowing each pixel to be accounted for in the image, so there is no blurred information.

 

Here's an image showing this concept. The original (256x256) is on the left, and the 2 images resized from it to the right.

 

 

Even this will not affect the outcome in many images, but I think it is good practice where it can be used all the same to avoid any potential complications, both on the RAM side and on the image quality side.