Here is a demonstration of a problem we are seeing were SDL window updates appear to stop after a wake from screenblank on Windows 10.

After waking from the blank (e.g. by pressing SHIFT) the debug output shows the main loop is still running, but the main window is ‘frozen’ on a single frame. This doesn’t happen every time, but is pretty much guaranteed within 10 attempts.

The app responds to SPACE to issue a Windows message to blank the screen, and the problem can be seen within a very few attempts

running from the command line allows a different renderer to be specified, and if set to ‘software’ or 'direct3d11' the problem does not occur.

Doing something that causes Windows to change something (e.g. pressing the start key to open the start menu or hovering over a window close button to pop up the “close” tooltip) will restore the updating.

The presence of other programs seems to affect the manifestation of this bug. e.g. if Notepad is running, then the problem will still happen. However if Alarms & Clock is running, then even if it’s on a static stopwatch display, then the problem will not occur - however if it’s subsequently minimised, then the problem will re-appear.

We are cross-compiling using mxe.cc and are currently on SDL2 2.0.12

/usr/local/opt/mxe.master/usr/bin/i686-w64-mingw32.static-g++ screensaver-nvidia-problem.cc -o screensaver-nvidia-problem.exe -L /usr/local/opt/mxe.master/usr/i686-w64-mingw32.static/lib -l mingw32 -l SDL2 -l SDL2main -l setupapi -l samplerate -l winmm -l gdi32 -l ole32 -l uuid -l imm32 -l version -l oleaut32

The problem appears to be exclusive to NVidia hardware.

This is possibly part of wider problem we are getting in extremely rare circumstances with a much larger app where windows stop updating for a few seconds, but after many hours of run time. But that has been almost impossible to provoke, let alone create a demonstration.