SDL2 2.24.2 (and older SDL2 as well) issues with RDP disconnecting?

[superfury]

I implemented two things:

• SDL_RENDER_DEVICE_RESET forces a display update in my app (if received).
• SDL_RENDER_TARGETS_RESET forces a full reload of all SDL rendering structures in the SDL1.2 compatible way (although leaving the window itself alone, not keeping the existing window).

Now, when SDL_RENDER_TARGETS_RESET is forced to trigger the reload of SDL1.2-compatible structures (in my app by minimizing and restoring the window from minimized state triggers this manually), the display isn't updated anymore? The only thing that seems to actually restore window update responsivity is connecting or disconnecting RDP?

Edit: Weirdly, the issue (as well as SDL_RENDER_TARGETS_RESET spamming after leaving RDP) seems to vanish with the latest builds, which enable the full video update on 2.24.2 and later when ran on Windows (and disabling the bugfix of SDL_WINDOWEVENT_RESTORED to trigger a forced texture update)). So in other words, the latest version is now properly working (although it's still strange that a reload of the textures on 2.24.2 causes an issue like that?).

The reason the reloading of just the textures in SDL2 2.0.2 up to 2.24.2 was moved to the SDL_WINDOWEVENT_RESTORED event was originally because SDL2 was spamming SDL_RENDER_TARGETS_RESET on that range of SDL2 versions (as in kept sending that event even though the reloading will only happen when once the window isn't minimized anymore).

[superfury]

OK. Just noticed something interesting: If an SDL2 2.24.2 app is started locally, everything behaves correctly during both local and RDP sessions.

But when the app is started during RDP and RDP is disconnected, the app won't respond anymore until at least viewed once locally (w/o RDP)? Windows itself locks to the lock screen btw when RDP connects.

So screen updates after RDP disconnect require to be viewed locally at least once for the app to stay responsive (and screen updates to display (changing the on-screen display of the changed pixels in the window)) somehow?

[slouken]

Windows has been optimized to no longer update the screen if it thinks nobody is watching. This includes the monitor being off and no RDP sessions active.

[superfury]

Windows has been optimized to no longer update the screen if it thinks nobody is watching. This includes the monitor being off and no RDP sessions active.

So does that include the (non-RDP local monitor) lock screen (b/c of RDP connect) combined with RDP connecting again(for a second time), preventing proper display updating for the app even though it's being rendered and other apps respond fine (stuff like Visual Studio etc. respond fine, just no SDL2 apps)?