Async Texture Loading

Unity Engine
1

Hi,

I’m not sure if it is in the pipe or somewhat related to the new WebResquest, but one developer told me on the forum that you planed to do async texture loading.

Right now Texture2D.LoadImage, is not async and when you want to do an app that is heavily UI based and you stream image from the web, it can be very frustrating to have the main/ui thread blocked.

So, is this something that is planed ?

2

“Graphics: Async Texture Upload” is under 5.3.

That said, that feature only deals with the CPU->GPU upload of texture data; it does not deal with, for example, decompressing image files themselves. That’s something you should be able to do on a background thread yourself, though.

3

Thanks for the reply,

How can I do this in a background thread since I need to call a UnityEngine function somewhere in the code to create the texture2D ?

4

You’d decompress the texture on a background thread into an array of Color32 elements (plus width and height), and then actually create the texture object on the main thread afterwards.

5

Welcome to the wonderful world of multithreading :wink:

I guess the keyword is synchronisation: The background thread cannot access UnityEngine, of course, but you can check the state of the work of the background thread from the main thread in regular intervals, and when you figured out that it’s done with its work, you can do that final step from the main thread.

6

So, we download a ton of PNG’s from the web, and the main issue we have is the time it takes to decompress the png into a Texture2D. One of our engineers played with moving this to a background thread, but the c# library for doing this work was many times slower that Unity’s built in one, making the delay much worse for the user. Is the only option here to make platform specific plugins for each platform and include libpng or something to do the decompression? It would be REALLY nice if unity’s internal PNG loader had this option, as writing a plugin for every platform we support is going to take a long time…

7

There are a couple options, none of them terribly appetizing.

www.texture is considerably faster than LoadImage(bytes)
www.textureNonReadable is also considerably faster than LoadImage(bytes)
LoadRawImageData() is considerably faster than either of the above, but requires you to have a previously compressed texture, which is either a massive filesize difference, or separately compressed/decompressed using say, lzma… (IE: a dds, or etc texture that has been offline compressed).

For the webgl build, where background decompression is not an option, I’ve got something where we load the texture data into a gltexture using native webgl, which is mirrored with a unity Texture2D using the nativetextureid, allowing the browser to cache/render the jpg’s. It ‘works’ but boy is that a lot of hassle just to work around the fact that there is no async loading of textures.

2 Likes