Asynchronous image loading to aid HDD bottlenecking

[oomek]

Have you ever considered a possibility of using async method on loadFromFile() or asynchronously load an image to memory and then call loadFromMemory() function?

In the current state Attract Mode is choking on fast updating artworks. When they are loadded from HDD the animations are freezing until reading finishes. Using SSD helps, but not everyone can afford one with a decent capacity.

[cosmicdan]

You seem to know what you're talking about - why not try it yourself and make a PR? ;)

I would try it, but I'm barely a code hacker when it comes to C(++). I wouldn't even know how to store the images in memory (creating some kind of ArrayList equivalent), let alone how to handle the buffer sizes (we obviously don't want to load EVERY image into memory, but rather the next/previous n amount), etc...

..unless by async you just mean loading images in a second thread (so it doesn't block the UI)?

[oomek]

You do not to have all the images stored in memory. It's just a matter to handle the image loading asynchronously to the main thread. SFML is not multithreaded, but It can be done in 2 ways. You create a separate thread which loads an image to the buffer, or you call async to load it in a lambda expression. Once you've checked it's done loading in the main thread you can load the texture from memory the normal way and it will be without any delay. I've tried async few day ago, but since textures in AM are not static objects I've had some compiler errors. I'm not a guru in c++ either, but I can try the multithreaded method later. You do not need to worry about the memory buffers management as it is done automatically and as long as you load a whole png to memory, not just a raw bitmap you just pass the &buffer[0] and buffer.size() to the loadFromMemory() function and it decodes automatically.

[popoklo]

i think this is a very important thing for AM, I stopped directly working on theme because of massive HDD loading for rapid fileloading.

[mickelson]

Closing as a duplicate of #179