love.graphics.newImage hanging

[BOT-Brad]

I'm trying to load in images both from the .love file and also the Love save-directory, however when attempting to do this for my required purpose, the entire LOVE application hangs for anywhere from 1 to 5 seconds. When the application resumes (With the images now loaded in), all of my setup timers and tweens and events have all already fired and finished, and the dt values returned by love.update are super high.

Is there anyway to stop .newImage from hogging up the application, and at least show some sort of "Loading" message or something?

[szensk]

Solution: Use a threaded image loader.

Question: how many/how big of images are you loading? 1-5s delay is quite long.

[bartbes]

Honestly, I'm not too convinced of the benefits of a threaded loader for images, since the final loading stage still has to happen on the main thread. I'd advice you to only load a few images at a time, then drawing a frame with the loading screen or whatever, then load some more, draw the screen, repeat. There's two easy ways to implement this, the first is coroutines, and the second is having a table with image paths to load, then taking the first few elements every time.

[s-ol]

Honestly, I'm not too convinced of the benefits of a threaded loader for images, since the final loading stage still has to happen on the main thread. I'd advice you to only load a few images at a time, then drawing a frame with the loading screen or whatever, then load some more, draw the screen, repeat. There's two easy ways to implement this, the first is coroutines, and the second is having a table with image paths to load, then taking the first few elements every time.

love-loader actually doesn't seem to be doing this, though I also thought that wasn't possible oO or maybe I just misread the source?

[bizziboi]

If you load on the thread to a binary blob, and create an image of that on the mainthread (assuming Love is built with a not shared context) you'd still have the main bottleneck (disk I/O) off the main thread which would be a significant win?

[Jasoco]

I too am curious as to how many images you're trying to load and how big they are. Because most projects won't ever take even a second to load all the resources. Can we see a .love file so we can understand your POV?

[BOT-Brad]

I am currently loading around 4 images that are about 1300x700 pixels and then around 30 that are 48x48 and 30 that are 128x128.

Ill post up a love shortly when I'm on desktop pc.

[riidom]

Ok, a few thoughts beforehand:

First, if you group the tiles to sheets, loading few big files should go smoother than loading many small ones.

Second, have you been on a laptop so far? Maybe one with a slow hard disc? I have one of these myself, and it suffers a lot from loading hiccups; I had to move some games and software to my fast but small SSD because it was so annoying. So maybe the problem wont appear on your desktop at all.

[Jasoco]

Yeah, please upload a .love. Even if it's just the images and loading code. I'm curious to see how fast it loads on my machines to get a benchmark. (I always prefer to break images into small pieces, if they're bigger than 1024x1024 or even 512x512. But don't know if that would make a difference.)

Also, could it be that since your large 1300x700 images aren't PO2 sized, maybe Löve is taking a long time to pad them? Those images, on a system that doesn't support PO2, but does support padding them, will be resized to 2048x1024 and I could see that being a pretty big bottleneck. (Providing the padding even adds time to loading. I don't know as I never had a machine that didn't support PO2.)

Try this, try timing how long it takes to do each image size group. Especially the large ones.

[BOT-Brad]

Here is a very quick demo I threw together. On my machine (Windows 7, 64-bit, Intel i3-2120 @ 3.3GHz, AMD Radeon 7860 GPU, 16GB RAM) this demo ALWAYS takes at least 5 seconds to load and then start producing its epileptic-fit inducing drawing cycle.