Using SplashScreen

Hi,

My app has quite a heavy loading process and I would like to have at minimum a splash screen to indicate users the app is loading. I tried using the SplashScreen class and run it async. My assumption was that it displays the image and then carries on with the loading process, but in fact the image only appears once the whole process is done, so no use.

Reading further the class example, I see that the loading process is then expected to run in a background thread. I had tried earlier but my problem is that I have a heavy audiograph to load and there seem to be assertions triggered when you try to load it on a separate thread.

Any way I can just display a plain image and then let my app carry on with its process normally?

Thanks for your help.

Mariano

possibly you could delay the heavy process some, until the image has been displayed. But it all would be very hacky. For example, you could set it up so that the load process is triggered by the paint routine of the component which holds your Image. but if someone were to do something that required your app to repaint (move/resize your window, drag another window over yours, etc), that would not happen, since it would be running your heavy loading process. another similar hacky solution is to somehow break the heavy loading code into some sort of state machine, that would run small pieces of it, giving time to other things on the message thread to actually happen.

For the delay, I have added a Thread::sleep(500) after the SplashScreen is instantiated, in case it needed a break to display, but that didn’t make any difference.

doh! that will not do it! lol… you just stopped the message thread from running, instead of letting it run for a time before starting the load. if you want to go this route, you could use a Timer. start the timer after the splash screen in instantiated, call your startup code in timerCallback, and stop the timer at the end of the callback. but again, this is a bandaid that will also have issues. aka this is not a correct solution

But won’t the timerCallback be on a different thread?

It looks like the cleanest option is to run the burden of the load on a separate thread, but as I did that I was facing various assertions for:

MidiInput::getDevices()
AudioDeviceManager::initialise
AudioGraphProcessor instantiation

I assume I’m not the only one having a complex audiograph to load at startup. How do people do it?

The Timer class just produces an event that arrives on the message thread. I don’t know the solution to this specific issue, as I haven’t needed to do this with an audio graph, I have dealt with the general problem on numerous occasions, and I’ve always done it on a separate thread. If I were working on this, I would spend time understanding the assertions, so that I might discover if the issues are resolvable. And/or, hopefully someone who has solved this will chime in. :slight_smile:

Yes, I guess I’ll need to dismantle my loading process into leaner parts that can be handled in the main thread and additional ones that can be performed in a background thread. Just wanted to check if there was any easier option.

Thanks a lot for your help, anyway. Much appreciated.