Flex Launcher sometimes closes itself when PC comes out of sleep mode

[ricprd]

I noticed this intermittent issue: there are times when I wake my system and I see the desktop instead of Flex Launcher. However, Flex Launcher was open the last time I used it (most of the time I even activate sleep mode by using a shortcut added to Flex Launcher via ":sleep").

Is there a way to check why Flex Launcher might be quitting like this?

[complexlogic]

Is it quitting, or is it actually crashing? This might be related to #23.

Flex Launcher stores image data in the GPU memory for rendering. The problem is that sometimes (likely depending on hardware or driver), the GPU memory is not preserved after a sleep/suspend operation. So when the PC wakes from sleep, Flex Launcher is tries to access the old GPU memory addresses which are now invalid, and causes the crash. This is my current theory.

The problem is that I can't replicate this issue in my setup. As I said above, it likely varies depending on hardware and/or driver. Could you try the build here and let me know if you still get the quit/crash behavior after sleep? That build uses CPU rendering instead of GPU rendering, which is less efficient, but it should isolate the GPU memory issue. So, if you don't experience the crash/quit, that would confirm the volatile GPU memory is the cause.

If that's the case, I can refactor the Flex Launcher code to free the GPU memory before sleeping, and re-render the images after waking up. That should provide a permanent fix for the issue.

[ricprd]

Is it quitting, or is it actually crashing? This might be related to #23.

I don't actually know. Is there a way to reliably check? The last time it happened, I checked the .log file but sadly it was blank.

The problem is that I can't replicate this issue in my setup. As I said above, it likely varies depending on hardware and/or driver. Could you try the build here and let me know if you still get the quit/crash behavior after sleep? That build uses CPU rendering instead of GPU rendering, which is less efficient, but it should isolate the GPU memory issue. So, if you don't experience the crash/quit, that would confirm the volatile GPU memory is the cause.

Thank you! I will check and report back :)

[ricprd]

That was quick, I already have an update: the issue happens even with this suggested build.

[paulxh]

Hi, just wanted to add my specific case here:

I have a mini PC that is connected to a TV via a HDMI cable and every time I started the mini PC first (which is configured to run in Kiosk mode so Flex Launcher is started as a custom interface) and waited a couple of minutes to start up the TV (so the mini PC would detect no external display initially) this happened:

Flex Launcher would be completely unresponsive in this state and I had to quit it and open a new instance for it to work properly.
After doing some tests and starting it in debug mode with seemingly no errors I did notice that sometimes some error logs that included keywords like D3DPOOL_DEFAULT and INVALIDCALL which seemed to link it to SDL2, so I found this issue and tried building a new version of the flex launcher using the cpu_render branch.

Lo and behold, this fixed the issue, so it seems you may have been right that this can cause issues in some cases. I suppose that my mini PC detects that there is no monitor so it doesn't use the GPU at all until I turn the TV on, which would send some sort of signal to mark the new input, but Flex Launcher is already running at that point so maybe it didn't get to properly initialize its images?

Just thought of leaving this here in case it helps anyone. Maybe think of including this fix in the master branch as well?
Sorry for bumping. Also, thanks for this very useful app. Your work is very appreciated.