Texture loading: projectM loads all textures/images into VRAM on startup

[OfficialIncubo]

I have added aprox. 25-40 HD textures to projectM. While I started the app on Android/Windows, it will take too long to load textures. It wastes my time. Can you fix this problem to load all the textures in a faster way?

[revmischa]

Sounds like a good area for improvement, I suggest you to profile that section of the code to find out why it is slow, optimize it, and open a pull request with your improvements

[kblaschke]

@Se7enSlasher Can you please provide one or more of those textures and the presets using them, if copyright allows?

Or at least give some specs about the textures like image dimensions, file sizes and compression algorithm used (JPG, PNG).

[OfficialIncubo]

Sorry for LATE response, but I can't attach the .zip file using my phone, so here is the link of my textures that I used: https://www.mediafire.com/download/e75gvwrm7gkfnfy
It contains +100 textures without using any compression software. Please don't view the full image. If you want to view them all, I am shame. The resolution of these images is 1280×720 and 1920×1080.
I am using preinstalled presets, but I added some of them that reads random texture code (I am also surprised with it 😀). I'll count 1000+ presets if I think of.... (sorry for my bad and incorrect language).
That's all. Hope it helps. 😉

[kblaschke]

Thanks, that'll make for a good test case!

The main problem with textures here is that projectM loads all available textures on startup, no matter if they are used in any preset or not. This takes some time and also a good amount of VRAM, so some kind of "lazy load" feature might be useful. It's not easy to do though as presets have no explicit list of textures they use, especially if they're sampling them in shaders or even randomly as you stated. I see some ways of improvement here:

• Add some kind of "intelligent" detection logic that finds texture references in presets, then loads them in a separate thread before displaying the preset. This will not work for all presets though as mentioned above.
• Profile the loader and see if the code is simply too slow (currently projectM uses https://github.com/SpartanJ/SOIL2) and replace it with a faster implementation.
• Defer texture loading from disk/storage into a background thread, which might break some presets at the beginning, but improve startup time.
• Limit/scale down texture resolution to reduce GPU upload time and VRAM usage (which is quite limited on mobile devices).

Also, always keep in mind that the file size of compressed images is way smaller than the VRAM they take up. A FullHD (1920x1080) texture takes up about 8 MiB of VRAM each, so if you have a hundred of them, that's 800 MiB VRAM - which is WAY more than most embedded or CPU-integrated GPUs have available in total.

[kblaschke]

Will at some point be fixed with issue #532 by only loading textures requested by the preset.

Besides that, adding huge textures will always add a performance impact due to time required for image loading. Milkdrop also suggests to only add textures up to 512x152 pixels to improve performance. Anything beyond that can't really be optimized by projectM.

[OfficialIncubo]

If the problem got solved, can I close it?

[kblaschke]

Sure.

The main issue, projectM loading all textures on startup, isn't solved though. Ideally, only one or two textures, depending on what the preset requests, should be loaded at the time they are required, and ideally in a separate thread (including shader translation etc.). There's still a lot of work to do, but I'll eventually get to it after the new build system is stable.

If you could solve this specific issue here on your own, please feel free to close the case. The remaining work will still be done in the other issue, you can watch it to see any progress if you like.

[kblaschke]

Closed the missing textures issue linked above, as this loading problem here is out of scope and still needs fixing.

There's a working branch in my fork where I started to rewrite the texture manager, but didn't really finish it yet due to other things being higher in the priority list for the 4.0 release.

This is what I'm going to do in the branch (some of those features are already partially implemented):

• Only load textures requested by a preset.
• Ideally, load the texture(s) in a separate thread (needs improving the "background worker" in class ProjectM so it can run over multiple frames instead of just a single pass, which doesn't do any good)
• Unload textures not used for a while, larger ones first.
• Improve random texture selection, e.g. do not use images with the same name as a preset file (thumbnail images).
• Make TextureManager more flexible so it can be fed with externally generated textures like noise and idle preset textures more easily, with a "keep indefinitiely" flag for some.