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: |
Can you try pasting this in to the code? The old Win32 code apparently used a hack where if resolution = native resolution, it used a borderless window instead of real fullscreen. This change should do exactly the same but with pure SDL3. |
|
Same issue. No change. |
Ok thanks for testing. Looks like a step by step approach is needed to identify the issue. It's tricky because it doesn't happen for me (much like oocube's Gnome issue). |
|
@phkb I have researched this more and I think the hardware mode switching logic was still somehow causing the delay I've branched from this PR's branch: #714 and tried again to simplify initialiseGLwithsize reducing it to just this which has no hardware mode switching logic (and is basically what Linux was doing): Please can you test and let me know if you still get the 5 second delay: https://github.com/mcarans/oolite/tree/common_iniitalisegl (packages https://github.com/mcarans/oolite/actions/runs/31928149423) If you do still get a delay, please can you tell me your screen resolution and monitor native resolution if different. "Flip model presents go as far as making windowed mode effectively equivalent or better when compared to the classic "fullscreen exclusive" mode. In fact, you may want to reconsider whether your application actually needs a fullscreen exclusive mode, since the benefits of a flip model borderless window include faster Alt-Tab switching and better integration with modern display features." |
|
I'm still getting the 4-5 sec delay switching between fullscreen and windowed.
(switching between windowed and full screen) |
|
@phkb Can you see if the latest changes on this branch helps? https://github.com/mcarans/oolite/tree/common_iniitalisegl In your logs from before the delays seemed small eg. If there are still issues, would you be able to add logging to see where the delay is occurring? |
|
Still having the same issues.
Time between the different sizes is how fast I was able to change from one mode to another. ie. Press F12, wait until display appears, immediately press F12 again. |
|
@phkb Hmm I need to narrow down where the delay is occurring. One suggestion from AI: check NVIDIA Control Panel → Set up G-SYNC. What is it set to currently? Try changing G-SYNC from "Enable for windowed and full screen mode" to "Enable for full screen mode only" if it isn't set to that already If you have that setting, can you see if it makes any difference? It would give a clue as to where the problem lies. Also, please try adding this before the SDL_SetWindowFullscreen call and let me know what it says: Also add instrumentation at the end (since we already established that between request and create surface, the time is short): |
|
Tried with G-SYNC on/off/fullscreen only/fullscreen+windowed and all had the same issue. Log file with extra info:
Pressing F12 as soon as the window was visible, 4 times in total. Watching the log while changing screen size, all the entries for each change would appear about 1 second after I pressed F12, then there is a further delay before I see anything in the window. It would appear that whatever the delay is, it's happening later in the process. I'll add some more debug messages and report back. |
Yes indeed. How strange! Thanks for testing. F12 calls toggleScreenMode which calls initialiseGLWithSize. The lines after initialiseGLWithSize in toggleScreenMode are: If that is being called, presumably the delay is somewhere in there. I was able to remove that call from resizing altogether without ill effect (already on master) so maybe it can be removed here too? I just tried on Linux and it seems to be fine. |
|
I did find this issue: libsdl-org/SDL#11041 |
Interesting, I hadn't seen that - it could be a clue. Please try adding logging before and after various calls using this function: Log like this: I also just found these issues which may be related: From the first of those two: Also can you try this (also from a comment in that issue)? Interestingly, that setting seems to also make fullscreen borderless any suitable SDL_WINDOW_FULLSCREEN window (which would normally be fullscreen exclusive)." |
|
From windowed to full screen
From full screen to windowed
|
I can also report that this works! Switching, alt-tab, everything is instantaneous again! Is this something all players with NVIDIA cards will need to do? Or is it because my card is a bit old now? |
That is excellent news! So glad you found that GitHub issue. What is happening for you is a Windows/NVIDIA OpenGL presentation-path problem triggered by SDL3's fullscreen window configuration (WS_POPUP). I don't think that it should be necessary for all Windows nVidia users to make changes (I have nVidia and don't need to do anything). I think a workaround should be possible, hopefully without reintroducing all the old Win32 code. |
|
@phkb Please try creating this function: After SDL_SetWindowFullscreen add: Run this with the original nVidia driver setting not "Prefer layered on DXGI Swapchain". Does this give a delay? |
|
No delay with the old setting. Success! |
|
@phkb please can you change the hack function to only remove WS_POPUP and give me this fuller log output: Also did you already remove the code below from toggleScreenMode? If not, can you try removing it to see if it makes any difference? If it can be removed, the entire doGuiScreenResizeUpdates can be removed as it isn't called from anywhere else from what I've seen. |
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.