SDL_WINDOW_ALLOW_HIGHDPI is pretty glitchy (especially with SDL_WINDOW_FULLSCREEN)

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• test case to reproduce most of issues described in bug (File.cpp, text/x-csrc, 2014-01-08 17:35:00 +0000, 2106 bytes)

Reported in version: 2.0.1
Reported for operating system, platform: Mac OS X 10.7, x86

Comments on the original bug report:

On 2013-11-06 17:49:21 +0000, philhassey wrote:

Overview:

SDL_WINDOW_ALLOW_HIGHDPI doesn't work very consistently, especially on second or third calls to SDL_CreateWindow.

Steps to Reproduce:

1. On my Macbook Air that has a 1440x900 (retina, so 2x pixels) screen, I request a SDL_WINDOW_ALLOW_HIGHDPI || SDL_WINDOW_FULLSCREEN.

2. This results in me getting a 1280x720 (retina) mode, which is strange, since it should be 1440x900.

(I then destroy the Window.)

3. If I then request a windowed mode, this works, however if I only call glViewport with the SDL_GL_GetDrawableSize right after changing it, often times, it doesn't appear correctly until I move the screen around. I have to repeatedly call glViewport each frame to be sure it works.

(I then destroy the Window.)

4. If I then re-request a fullscreen mode at 1440x900 with HIGHDPI and FULLSCREEN, I end up getting a 1440x900 (retina) mode just like I wanted in the first place. Unfortunately, it is not retina, so SDL_GL_GetDrawableSize tells me 2880x1800, at first ... but if I use glViewport ONCE it only gives me the top-left-corner of my screen. What happens next, is if I repeatedly call SDL_GL_GetDrawableSize each frame, it returns 1440x900 after that first call, BUT glViewport doesn't correct, because while the screen isn't in retina mode, the view I was given seems to actually be 2880x1800 (taking up 4x the screen size. So by changing the viewport, I end up selecting parts of the view that aren't on the screen at all, resulting in a black screen.)

On 2014-01-07 02:41:37 +0000, (disabled) Jørgen Tjernø wrote:

You said 'SDL_WINDOW_ALLOW_HIGHDPI || SDL_WINDOW_FULLSCREEN', do you mean 'SDL_WINDOW_ALLOW_HIGHDPI | SDL_WINDOW_FULLSCREEN'?

Also, using regular fullscreen should allow you to create windows with 2880x1800 directly, that should not require SDL_WINDOW_ALLOW_HIGHDPI to be retina (AFAIK.)

If you use SDL_WINDOW_FULLSCREEN_DESKTOP (or create a windowed mode), you need to OR in the SDL_WINDOW_ALLOW_HIGHDPI switch.

Also, the specific code you run for each scenario would be appreciated to clarify what causes the problems.

On 2014-01-08 17:35:00 +0000, philhassey wrote:

Created attachment 1516
test case to reproduce most of issues described in bug

reproduces all non-visual symptoms described in bug report.

On 2014-01-08 17:36:19 +0000, philhassey wrote:

Sorry for the typo. I've attached a test case the reproduces all the non-visual things I reported. Here's the log from my retina Mac (comments below):

$ ./sdltest3.app/Contents/MacOS/sdltest3
SDL_GetDesktopDisplayMode: w=1440 h=900

Step 1...
_init_video(1440,900,8199)
SDL_GetWindowSize: w=1280, h=720
SDL_GL_GetDrawableSize: w=2560, h=1440
glViewport(0,0,2560,1440); SDL_GL_SwapWindow();
SDL_GL_GetDrawableSize: w=2560, h=1440
glViewport(0,0,2560,1440); SDL_GL_SwapWindow();

Step 3...
_init_video(1080,675,8198)
SDL_GetWindowSize: w=1080, h=675
SDL_GL_GetDrawableSize: w=2160, h=1350
glViewport(0,0,2160,1350); SDL_GL_SwapWindow();
SDL_GL_GetDrawableSize: w=2160, h=1350
glViewport(0,0,2160,1350); SDL_GL_SwapWindow();

Step 4...
_init_video(1440,900,8199)
SDL_GetWindowSize: w=1440, h=900
SDL_GL_GetDrawableSize: w=2880, h=1800
glViewport(0,0,2880,1800); SDL_GL_SwapWindow();
SDL_GL_GetDrawableSize: w=1440, h=900
glViewport(0,0,1440,900); SDL_GL_SwapWindow();

--

Comments:

• Step 1: Expected the window size to be 1440x900 as requested. Result: 1280x720.

• Step 3: This seemed to work (my test case doesn't reproduce accompanying visual problems.)

• Step 4: Expected the drawable size to be 2880x1800 and for it to stay at that size. Result: 2880x1800 and then changed to 1440x900. (my test case doesn't reproduce accompanying visual problems.)

Hope that gives you enough to go on!

On 2014-09-04 02:07:43 +0000, Eric Wasylishen wrote:

Here is a simple test case where SDL_WINDOW_ALLOW_HIGHDPI breaks SDL_WINDOW_FULLSCREEN:

(on 15" macbook pro retina (2880x1800), OS X 10.9.4):

• launch testgl2 (included with sdl2) with "--allow-highdpi"
• press Ctrl+Enter
• expected: fullscreen spinning cube. observed: black screen
• press Ctrl+Enter again to exit fullscreen
• exected: spinning cube window is restored. observed: the window is restored to its correct original size, but the contents are garbled. Part of the demo is rendering in the top left quadrant of the window, the rest is garbage / noise.

On 2017-08-15 04:46:54 +0000, Sam Lantinga wrote:

Eric is working on a patch to address this.

On 2017-08-15 19:48:29 +0000, Eric Wasylishen wrote:

The steps in comment # 4 still reproduce on current hg and macOS 10.12.6.

Interestingly, if I plug in an external monitor beforehand, I get the spinning cube in fullscreen (going fullscreen on the highdpi laptop screen, not the external monitor) but the window is still corrupted when returning to windowed mode.

[icculus]

Putting this in 2.0.18 to examine and maybe push away or close as fixed.

[ericwa]

Testing some old highdpi bugs..

On 2014-09-04 02:07:43 +0000, Eric Wasylishen wrote:

Here is a simple test case where SDL_WINDOW_ALLOW_HIGHDPI breaks SDL_WINDOW_FULLSCREEN:
(on 15" macbook pro retina (2880x1800), OS X 10.9.4):

• launch testgl2 (included with sdl2) with "--allow-highdpi"
• press Ctrl+Enter
• expected: fullscreen spinning cube. observed: black screen
• press Ctrl+Enter again to exit fullscreen
• exected: spinning cube window is restored. observed: the window is restored to its correct original size, but the contents are garbled. Part of the demo is rendering in the top left quadrant of the window, the rest is garbage / noise.

This no longer repros for me (macOS 10.15.7, SDL release-2.26.1). For reference, I built the SDLTest.xcodeproj in Xcode 12.4. Deployment target is set to 10.9 in the SDL xcodeproj's. I had to give the testgl2 target an Info plist (just used TestDropFile-Info.plist and set NSHighResolutionCapable to YES in order for --allow-highdpi to work.

I also ran the original attachment from 2013 and got this:

2022-12-27 13:35:17.227235-0700 testgl2[6146:39182] Metal API Validation Enabled
SDL_GetDesktopDisplayMode: w=1440 h=900

Step 1...
_init_video(1440,900,8199)
SDL_GetWindowSize: w=1440, h=900
SDL_GL_GetDrawableSize: w=2880, h=1800
glViewport(0,0,2880,1800); SDL_GL_SwapWindow();
SDL_GL_GetDrawableSize: w=2880, h=1800
glViewport(0,0,2880,1800); SDL_GL_SwapWindow();

Step 3...
_init_video(1080,675,8198)
SDL_GetWindowSize: w=1080, h=675
SDL_GL_GetDrawableSize: w=2160, h=1350
glViewport(0,0,2160,1350); SDL_GL_SwapWindow();
SDL_GL_GetDrawableSize: w=2160, h=1350
glViewport(0,0,2160,1350); SDL_GL_SwapWindow();

Step 4...
_init_video(1440,900,8199)
SDL_GetWindowSize: w=1440, h=900
SDL_GL_GetDrawableSize: w=2880, h=1800
glViewport(0,0,2880,1800); SDL_GL_SwapWindow();
SDL_GL_GetDrawableSize: w=2880, h=1800
glViewport(0,0,2880,1800); SDL_GL_SwapWindow();

Looking back on the thread under "Comments:" neither of the issues are happening (the reported bugs were that the first SDL_GetWindowSize call showed a smaller window than was requested, and under Step 4 the two SDL_GL_GetDrawableSize calls returned different things).

So I think this can be closed as fixed.

[slouken]

Thanks!