Refresh glConfig window and UI viewport sizes when the GL context is set up

[jm2]

Split out of #174.

glConfig.vidWidth/vidHeight and the uiViewport* rect were only refreshed in GLimp_SwapBuffers. As a result, anything running between GLimp_Init / GLimp_SetScreenParms and the first present of a new mode laid itself out from the previous mode's numbers. This moves the refresh into SDL3_SyncGLConfigWindowDimensions() and calls it from all three places. The Vulkan backend already refreshes these values at init (vk_Backend.cpp), so the change is GL-only.

What was tested, and what wasn't

• macOS arm64, OpenGL (Apple GL 2.1 compatibility path), windowed at 2560x1440. At the main menu: vid_restart, then r_screenFraction 75 + vid_restart, then screenshot.
• The same script was run on 71c3230c without this change. The screenshots are identical, and the menu lays out correctly in both. No visible before/after was found in this scenario, so this is offered as a correctness change rather than a proven fix for Bug - Scale Resolution #169.
• renderer_classic_gui_domain.py, gui_clipping_contract.py and macos_renderer_backend_policy.py pass.
• Not tested on Windows or Linux.

Refs #169, #174.

🤖 Generated with Claude Code

https://claude.ai/code/session_017RU1i6R3gN4cdKRELGiCEc

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[jm2]

Only macOS (M1 Max) has been tested so far. Windows and Linux runs are in progress, and results will be added here shortly.

[jm2]

Windows and Linux results. Commits: base 71c3230c, this PR 98cce227.

	Windows 11, RX 6400, Adrenalin 25.10.30.02	Fedora 44 (Wayland), RX 6400, Mesa 26.2.2
vid_restart, then r_screenFraction 75 + vid_restart	menu full-size and text intact on both builds, same bounds	both builds pixel-identical
window 1280x720 → 1024x768 + vid_restart	menu fills 1024x768 on both builds, same layout	same layout and text bounds; only glyph-edge anti-aliasing differs (mean abs diff 0.96/255)
new warnings/errors vs base	none	none
renderer_classic_gui_domain, gui_clipping_contract	pass	pass

No visible before/after difference showed up on any of the three platforms. Every vid_restart in these runs went through a full renderer restart, so they exercise the GLimp_Init call. None of them reached GLimp_SetScreenParms. On Windows, base already reported the correct 1024x768 right after vid_restart.

This is still offered as a correctness change with no observed regressions, not as a demonstrated fix for #169.

Notes on the method: in windowed mode the size comes from r_windowWidth/r_windowHeight (not r_mode/r_customWidth), and it has to be changed mid-run, because command-line +set values are all applied at startup.

[themuffinator]

Taking this, and thank you for splitting it out and for being straight that you found no visible difference. That is the right way to offer a correctness change.

The gap is real, and there is a comment in the tree that says so. SDL3_SetUIViewport mirrors into glConfig only under #ifndef OPENQ4_RENDERER_MODULE_ONLY, with the note "module renderers poll this state through the window services each present". The module renderer is what we ship by default, so before this change the only refresh a module build got really was the one in GLimp_SwapBuffers — anything between context setup and the first present of a new mode was reading the previous mode's numbers.

I could not find a visible difference on Windows either. At the menu on GL, captures across vid_restart, r_screenFraction 25/50/200 and back are pixel-identical to main at every step. So this lands as a correctness change on both platforms, not a fix.

It is not the cause of #169, and I have found what is

While testing this I reproduced #169 on Windows x64 / OpenGL, and it is not a stale-dimensions problem. r_screenFraction below 100 degrades the 2D menu pass itself. Menu sharpness, mean absolute luminance gradient over the whole frame, each value applied with a vid_restart:

r_screenFraction	r_resolutionScaleMode 1 (default)	r_resolutionScaleMode 0 (legacy crop)
100%	0.2406	0.2406
50%	0.2178	0.1264
25%	0.1943	0.0483
200%	0.2406	0.2406

Supersampling leaves the menu untouched; only downscaling reaches it. On mode 0 it is not even subtle — the menu is drawn into a quarter-size viewport in the bottom-left corner with the rest of the screen black.

That matches AdrielXXO's screenshots, where the Settings page is soft at 25%. The cvar is documented as the main-scene resolution scale and there is a uiViewport path whose whole job is to keep 2D at native size, so the 2D pass is going through the scaled target when it should not. Details are on #169.

Builds clean on MSVC; renderer_classic_gui_domain.py, gui_clipping_contract.py and macos_renderer_backend_policy.py pass.