is one single 3.5MB sprite atlas to big to push on the gpu on mobile devices?

[valueerror]

i am using a sprite atlas in my game that contains ALL images i need..  i create everything out of this atlas (animations, sprites, buttons)

 

i am using webGL!

 

the atlas "allsprites.png" is around 3.5MB  and i was wondering if it may be a little bit too much for a mobile gpu to get 3.5 mb on every frame..  i tried to scale down everything to 75%  an the file was 1.2MB then..   profiling in chrome didn't show any difference. (rendering, scripting, and painting times were almost the same)

 

 

why didn't i see any difference in cpu/memory usage..  even the Garbage collector collected almost the same amount and was fired as often

 

 

 

 

 

thats why i'm asking for your experience here:  is 3.5 to big ?  what sizes (MB) do you usually impose on a gpu in a rather complex game (like angy birds)

 

thx in advance

[lewster32]

Is this 3.5mb as a .png file? It's hard to say without knowing dimensions (which are what really matter in this case - file size only impacts the downloading/preloading phase, as all assets are decompressed to 32-bit images for use) but as a general rule, 2048x2048 is the sensible maximum size you should use for an atlas. Lots of devices support larger (4096x4098 and onwards) but it's best to stick to 2048 for now.

[valueerror]

3.5mb PNG file yes! And its dimensions are 2048x2048

Half of the image is transparent .. I could go much lower without to power of two rule.

[lewster32]

That'll be fine, though you may wanna run it through tinypng which usually gets the file size down a lot for very little (and in most cases imperceptible) loss of image quality. Remember also that PoT rules allow different powers for each dimension, like 2048x1024, so if most of your image is transparent that'll be a valid size.

[valueerror]

thx lewster..  tinypng (or pngquant) is not able to reduce the size of this png further without introducing a quality loss i don't want ...  it's a little bit confusing.. i can reduce the quality of all single images with pngquant (without any visible losses) but saving it as atlas will make it bigger again...  reducing the atlas will lead to very visible changes in all gradients and semitransparent areas..  (a lot of dots)  i actually dont get why i can reduce the size of one of the images but not the atlas image but as you said.. the dimensions matter more because the image is decompressed anyway..  i forgot about that fact..  thx..  

[SolarJS]

2048 x 2048 is Fine with your Device, 4096x4096 is not supported broadly. Also, the Upload to the gpu only apples pnce. That is the reason you dont see any differences in speed. Also, tinypng may compress the file size, but this is not the size it Users in GPU memory.

[lewster32]

The compression optimisations affect the image itself, not its component images, so if you save lots of 8-bit pngs and then combine them into a 32-bit png, you undo all your good work. One of my specialities is file compression, so if you want me to have a look at it I may be able to provide some tips on how to optimise it better? 3.5mb is a lot for a texture atlas and I'd normally only expect a file size like that from trying to compress photographic sources, heavily textured images or images with a lot of noise and/or detailed patterns.

[lewster32]

Yeah, none of this affects performance, but a 3.5mb asset is rather a large thing to download if you're targeting the kind of devices that only support 2048x2048 (i.e. mobile)

[valueerror]

i have a lot of high detailed sprites with textures and gradients..  i thought about simplifying my graphics to create a less realistic and more comic kind of style. then the compression would be much better.. thx lewster for your support but i think pnquant and imagemagick (two very nice console tools) are so much help - i will manage it on my own

 

as for the filesize... if it does not matter for the gpu i don't think it matters at all in my case..

 

i would package it as apk with crosswalk..   the complete game (all files/assets) is about 6mb but then with crosswalk  its around 20mb .. so those 1-3mb actually don't matter that much - for downloading the app, crosswalk is a much bigger factor.

 

still i am thinking of reducing the image size by 25%  so every 32x32px sprite will be 24x24 - the resulting atlas would be only a third of its size (in MB) and i guess that means that the decompessed graphics loaded onto the gpu will be a lot smaller to..  this has to matter somehow for performance ... doesn't it?  maybe it will be visible on slower devices only and not on desktops

[SolarJS]

Roughly one can say, that size of a texture does only matter to performance, if the objects are too big for a low end device screen. For that case you should have two sets of textures. For example one for low end / low resolution devices and one for high end and tablets.

[ericjbasti]

Just so you understand what tinypng is doing (and why it looks so bad on the entire atlas). It's actually taking your png down from a 24bit png to an 8bit dithered png. However unlike the 8bit png you would save out in most programs with 1bit transparency they are able to use 8bit transparency. This works great when you don't have a lot of variation in colors, but throw in a few gradients and a lot of colors and you will see the difference. 

 

You might want to look into not using the optimized images to build out your atlas. I suspect you won't notice much of a file size difference.

[valueerror]

thank you all for your thoughts on this

 

@solarJS:  that sounds like a good idea but most of the hitboxes are set manually.. also some polygons that i created manually would need adjustment.. so i have to programm some hooks to load the right sizes of the physics shapes but this shouldn't be that much of a problem

 

@ericjbasti:  i am familiar with what pngquant does for the most part - thank you nevertheless..  the interesting thing with the atlas is that if i apply pngquant to the single images the atlas is made of it works perfectly..  all gradients and shadows look perfect..  indistinguishable from the original but half the filesize

if i use pngquant (or tinypng which uses pngquant in the background) on the atlas it applies dithering..  i don't know why it does that..  first i thought that maybe the atlas creation is somehow already using something like pngquant (even if i told texturepacker not to use any png optimization - or if i used spritesheetpacker instead) so i tried what happens if i use pngquant on the same image twice but the result was - nothing.. if i run it twice nothing changes.. so this isn't the case with my atlas it must be something else..

[xerver]

@valueerror just an FYI for the future, the size of your file is irrelevant because that will take into account the format and compression, etc. All that matters are the dimensions, because once it is in memory it is a byte array of rgba values regardless of what the format of the file was before.

 

You can checkout stats about "what is the support like for X in WebGL" at http://webglstats.com/. Specifically for this, scroll to the bottom and look at "MAX_TEXTURE_SIZE". Your image has a texture size of 4096 and is supported by 98.6% of all WebGL enabled browsers. You can filter to devices you are interested in on the left side.

[rich]

Exactly as Chad said, dimensions are the important part. The rest is just the over the wire cost. There are techniques you can use to get it down though, ShoeBox has a great feature where you can convert it into a JPG + a PNG alpha mask, which unless you're using pixel art works really well in lots of cases.

[ericjbasti]

With the png compression its the difference between 256 colors and millions of colors. Once you make the atlas, the amount of colors increases so much that the switch to 256 becomes much more noticeable. That final 8bit png can only have 256 colors. If you group only images with similar color palettes the change will be much less noticeable, but as soon as you introduce an image with a different set of 256 colors, you'll essentially converted both images to 128 colors. This becomes a problem fast. Soon its a bunch of ugly 16 color images. Your atlas will be fine with a 24bit image unless you can break it into multiple atlases grouped by color palette.

[BdR]

Sorry to bump this thread, but which tool or tools do you use to create the files for a sprite atlas?

 

I'm working on a game and texting on CocoonJS now and it's using 7 PNG images during the game. I suspect it might perform better when I put all sprites in 1 file instead of several files.

[clark]

@BdR https://www.codeandweb.com/texturepacker

 

I would use TexturePacker purely because its cheap, and its perfect plus the AutoSD settings generate all the resolutions we need from a single button click.

[SolarJS]

TexturePacker is definitely the crop of the cream tool you can even define your own packed output. If you want to go for free tool try Shoebox at http://renderhjs.net/shoebox/