Skip to content

Windows sdl3 cleanup - #709

Draft
mcarans wants to merge 6 commits into
OoliteProject:masterfrom
mcarans:win_sdl3_cleanup
Draft

Windows sdl3 cleanup#709
mcarans wants to merge 6 commits into
OoliteProject:masterfrom
mcarans:win_sdl3_cleanup

Conversation

@mcarans

@mcarans mcarans commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

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.

oocube
oocube previously approved these changes Aug 8, 2026

@oocube oocube left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The window under Ubuntu Gnome is not controllable. But that was not the intent of the fix. After all the situation has not worsened.

@mcarans

mcarans commented Aug 8, 2026

Copy link
Copy Markdown
Contributor Author

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.

@phkb

phkb commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

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.

@mcarans

mcarans commented Aug 9, 2026

Copy link
Copy Markdown
Contributor Author

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

@phkb

phkb commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

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.

@phkb

phkb commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Some more observations.
When in fullscreen mode, and the game has the focus, pressing Alt-tab to switch to another application also causes a 4-5 second black screen delay. I also don't see the window thumbnails when I press Alt-tab, so I can't tell which app I'm switching to. I have to hold down Alt for those 4-5 seconds, at which point the thumbnails appear.

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.

@phkb

phkb commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

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.

@mcarans

mcarans commented Aug 9, 2026

Copy link
Copy Markdown
Contributor Author

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?

@phkb

phkb commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Does any of this happen with current master?

No, current master is fine.

@phkb

phkb commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

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).
@mcarans

mcarans commented Aug 9, 2026

Copy link
Copy Markdown
Contributor Author

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.

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:

Default to Borderless / Desktop Fullscreen (SDL_SetWindowFullscreenMode(window, NULL)), which runs fullscreen at native display resolution without mode-switching delays.

Only set an explicit mode if v_mode is YES AND the requested resolution is different from the current desktop mode resolution."

It sounds plausible. The fix I checked in does the resolution check and seems instant on my computer. Does it help on yours?

@phkb

phkb commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Same issue I'm afraid. No change.

@oocube

oocube commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Ah, this is about real full screen mode. I was just maximizing the window, which remains in windowed mode.
Yes, I think other applications also show a delay when switching to/from windowed into full screen mode?

@mcarans

mcarans commented Aug 9, 2026

Copy link
Copy Markdown
Contributor Author

Ah, this is about real full screen mode. I was just maximizing the window, which remains in windowed mode. Yes, I think other applications also show a delay when switching to/from windowed into full screen 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?

Same issue I'm afraid. No change.

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.

@mcarans
mcarans marked this pull request as draft August 9, 2026 19:01
@mcarans

mcarans commented Aug 9, 2026

Copy link
Copy Markdown
Contributor Author

@phkb Please can you add logging like this after BOOL isDifferentResolution... and post what is logged.

OOLog(@"display.initGL.debug", @"[DEBUG] DisplayID: %u | Desktop: %dx%d | Requested: %dx%d | v_mode: %d | isDiff: %d",
      (unsigned int)displayID,
      desktopMode ? desktopMode->w : 0, 
      desktopMode ? desktopMode->h : 0,
      (int)viewSize.width, 
      (int)viewSize.height, 
      v_mode, 
      isDifferentResolution);

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 SDL_SetWindowFullscreenMode(window, NULL); path is taken to see if that makes any difference.

@phkb

phkb commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Results from debug line:
07:11:22.839 [display.initGL.debug]: [DEBUG] DisplayID: 1 | Desktop: 1920x1080 | Requested: 1920x1080 | v_mode: 1 | isDiff: 0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants