Fastest way to load PNG assets?

[David Kalina]

Hello,

Our load times on older mobile devices (e.g. iPad2) are dismal.  We load quite a bit of 2D art, all of which is stored in PNG Atlas style sprite collections.

Anyway, after doing some research on the interwebs, I discovered that the standard 2DToolkit method for loading PNGs (calling LoadImage on a TextAsset's bytes followed by Apply) is quite a bit slower than loading the asset using Resources.Load.

I hacked together a test -- put one of my 1024x2048 .png assets into Resources and loaded it both ways on an iPad 2 -- and lo and behold, the LoadImage / Apply method timed at about ~0.75 seconds vs ~0.13 seconds for using Resources.Load.

I'm curious if there's some reason I shouldn't just be spitting built sprite collection .PNGs into /Resources with unique names, saving those names in the tk2dSpriteCollectionData, and then loading them via Resources.Load instead. 

Additionally, this isn't accounting for the benefit of not having to load those PNG TextAssets just to create the actual Texture2Ds, which Unity automagically does if the Sprite Collection is referenced in a level anywhere.  It certainly seems like it warrants a further experiment on my end, unless there is some clear reason this won't work that I am missing. 

So is there some clear reason this won't work that I'm missing? 

Thanks in advance!
David

[unikronsoftware]

I don't see why this wouldn't work - as long as you make sure the texture is loaded in time for the sprite collection it should work fine.

[39thstreet]

Additionally, this isn't accounting for the benefit of not having to load those PNG TextAssets just to create the actual Texture2Ds, which Unity automagically does if the Sprite Collection is referenced in a level anywhere.  It certainly seems like it warrants a further experiment on my end, unless there is some clear reason this won't work that I am missing. 

Thanks for this thread as we've been looking into some slowness with our PNG loads!

We're trying to use this method to improve load times on our png assets, but when we try to load the .png.bytes files via resources.load we aren't able to cast them as a texture2D, is there another step to this we are missing?

Did you end up doing this, and if so, do you have any implementation tips?

TIA!

[unikronsoftware]

You can't, as far as I know. The .bytes files is just a byte stream.

[David Kalina]

Yes, I had the knucklehead realization that putting them into Resources as .png files (rather than .png.bytes) has the same effect as using Unity textures in the first place -- totally uncompressed textures in the package.  So yes, loading becomes radically faster...  and your 2.6MB 2048x2048 becomes 16MB on disk.  Fuuuuuuck Unity and its lack of native PNG support, seriously.

I did continue to go in this direction though, choosing to put all PNG Atlases in Resources as .png.bytes and loading them as TextAssets before upload.  This ultimately doesn't *directly* help with load times (still has the massive spike associated with converting a PNG and uploading it to the graphics hardware), but there were positive indirect benefits:

- Our levels point at SCs that are not needed at load-time, this allows us to only load the TextAssets and convert them to Texture2Ds when we actually need them.
- ...which reduces memory footprint and level load times.
- ...and allows us to actively manage SC memory while travelling between sections of levels that have different SC needs, keeping max footprint down.

All of this for the love of the iPad 2

[unikronsoftware]

I'm just gonna throw this out there but depending on the amount of time you have available for the project, you could load the texture (png) yourself, decode and fill the Texture2D ALL from a native plugin, without crossing any language boundaries whatsoever... Unity now has the native textureptr exposed which is great for stuff like this. Its still a fair bit of work to implement though.

[Sickwitit]

Why not just create an object pool, load all your png assets into the object pool when the game starts, deactivate the objects , then just activate those objects when you need them, and deactivate when you don't, instead of trying to accessing your atlas constantly during runtime.

This may be trolling, but thought i'd give the quick fix suggestion.