Windows sdl3 cleanup - #709
Conversation
oocube
left a comment
There was a problem hiding this comment.
The window under Ubuntu Gnome is not controllable. But that was not the intent of the fix. After all the situation has not worsened.
Yes this does not have the Gnome fix. Thanks for confirming Linux is the same. This PR cuts out a load of Windows specific code no longer needed with SDL3. More cleanup will come in another PR after I merge this one assuming @phkb confirms this one doesn't break anything on Windows. |
|
Generally everything seems to work as expected. However, there is now a 4-5 second delay whenever the F12 (fullscreen) button is pressed before the visuals are restored. That's going both ways, from full screen to windowed, and from windowed to full screen. There was almost no delay before. When in game, the clock keeps running during that delay, so for those 4-5 seconds you're flying blind. |
I just tested again and I don't have this issue. For me the transition is immediate both ways. Is there any clue in the logs? Can you tell me more about your setup? Also just to make completely sure, did you do a clean and build (I've noticed occasional odd behaviour without a clean)? Also on the offchance this improves it, I had made further refactorings on a branch taken from the PR's branch. Does this make any difference? https://github.com/mcarans/oolite/releases/tag/1.93.1-win-sdl3-cleanup2.2 |
|
I'm running a Win11 Pro 25H2 build, 32GB RAM, Intel 12th Gen i5-12400F, with an NVIDIA GTX 1660. Logs are clear - no errors or unexpected messages. Issue also happens with the "cleanup2" build. |
|
Some more observations. If I turn on HDR, going from windowed to full screen is instantaneous. Going back from full screen to windowed has the 4-5 second black screen delay. |
|
Oh, and if switch back to full screen Oolite (either with alt-tab or just by clicking on the app in the task bar, I again get that 4-5 second black screen delay. |
Does any of this happen with current master? |
No, current master is fine. |
|
Just for kicks, I also re-ran the setup for the build environment, in case there was something out of date (for whatever reason). But the issue persists. |
…ktop mode. If the requested window size matches the desktop resolution, it sets SDL_SetWindowFullscreenMode(window, NULL) (Desktop Fullscreen).
AI claimed "The 5-second delay you are seeing on certain setups is caused by Hardware Display Mode Switching (Exclusive Fullscreen Mode). When switching in or out of true Exclusive Fullscreen—or Alt-Tabbing away from it—the Windows GPU driver and the monitor must physically renegotiate display parameters (resolution, refresh rate, color depth, and HDCP/HDMI/DisplayPort handshakes). On modern high-refresh-rate monitors, VRR/G-Sync/FreeSync displays, or multi-monitor setups, this handshake routinely causes a 3–5 second black screen / delay... Your old Win32 code explicitly checked whether the requested mode was actually different from the current desktop mode. If the requested game resolution matched the desktop resolution, the old code skipped the display mode change entirely, keeping the OS in desktop windowed mode under the hood. The new SDL3 code bypasses this logic and always requests a hard mode change when v_mode is active... To eliminate the 5-second delay: It sounds plausible. The fix I checked in does the resolution check and seems instant on my computer. Does it help on yours? |
|
Same issue I'm afraid. No change. |
|
Ah, this is about real full screen mode. I was just maximizing the window, which remains in windowed mode. |
Are you saying that there is a new issue in this PR with a delay switching to/from windowed into full screen mode on your system or are you saying all applications for you exhibit a delay switching to/from windowed into full screen mode (ie. no change)? If you do see a new issue, does it also happen with master?
Hmm, ok. Thanks for testing. I'll have to introduce smaller changes step by step to see which one affects your system. Setting to draft for now. |
|
@phkb Please can you add logging like this after It could be that the if statements that follow are always evaluating to True. If so, please could you try forcing them to false as a test so the |
|
Results from debug line: |
Clean up of Windows code
Also uses same debouncing of resizing as Linux
Tested on Windows and Linux. Also tested fullscreen, exit game and reload - worked fine for me.