We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3598

Summary: OS X full screen retina; GL drawable getting downsized immediately after creation
Product: SDL Reporter: Oliver Collyer <ovcollyer>
Component: renderAssignee: Alex Szpakowski <amaranth72>
Status: RESOLVED ABANDONED QA Contact: Sam Lantinga <slouken>
Severity: blocker    
Priority: P2 Keywords: target-2.0.6
Version: 2.0.5   
Hardware: x86_64   
OS: macOS 10.12   
Attachments: Test project illustrating the issue

Description Oliver Collyer 2017-03-02 17:39:33 UTC 
Created attachment 2701 [details]
Test project illustrating the issue

Run the attached test project on a Retina MacBook Pro and you should see an alternating R/G/B background and a black square drawn towards the top left.

When using SDL_WINDOW_FULLSCREEN_DESKTOP this works correctly.

When using SDL_WINDOW_FULLSCREEN the GL context gets scaled down to half the size it should be by an event immediately follows creation of the window.

Note that in order to see this bug you will first need to fix some other bugs that hide this problem, which are detailed here:

https://bugzilla.libsdl.org/show_bug.cgi?id=3587

Apply the changes suggested in the above bug report to SDL2-2.0.5 code, modify the attached project to link to your SDL2 framework and then then run this project and you should see the following trace:

>>>>>

Renderer output size is 2880 x 1800 (before events)
Received SDL_WINDOWEVENT:
  timestamp = 245
  windowID  = 1
  event     = 5 (SDL_WINDOWEVENT_RESIZED)
  padding1  = 104
  padding2  = 144
  padding3  = 64
  data1     = 1440
  data2     = 900
Renderer output size is 1440 x 900 (after event)

<<<<<

A high-DPI Window of 1440 x 900 is requested and initially the renderer output size is the expected 2880 x 1800, however after SDL_WINDOWEVENT_RESIZED is sent (for whatever reason) it gets reduced to 1440 x 900 i.e. no longer high-DPI.

This does not occur when using SDL_WINDOW_FULLSCREEN_DESKTOP.

This is on macOS Sierra.
Comment 1 Oliver Collyer 2017-03-03 13:47:30 UTC 
Just updating following more investigations.

If I disable the call to SDL_PollEvent it stops the GL context resizing.

From within there it ends up at NSApplicationDidBecomeActiveNotification (the function is called windowWillClose)....at this point the GL context has been resized.

So at some point between window/renderer creation and the application handling the above notification it is messing with the context or view or something, meaning the drawable size get halved.
Comment 2 Sam Lantinga 2017-08-11 19:10:37 UTC 
Alex, can you take a look at this for the SDL 2.0.6 release?

Thanks!
Comment 3 Alex Szpakowski 2017-08-12 00:33:39 UTC 
Using SDL 2.0.5 I get some weird fullscreen mode behaviour (although not what you described).
But when I use the latest SDL code from hg everything works as expected:

- The fullscreen display mode switches to 1440x900@2x (2880x1800 pixels) right when the window is created
- SDL_GetRendererOutputSize correctly reports 2880x1800 pixels, and the window size is 1440x900 points.
- A resize event occurs but it still correctly reports a window size in points of 1440x900 (and SDL_GetRendererOutputSize continues to correctly report 2880x1800 pixels).

Can you confirm this on your system?
Comment 4 Ryan C. Gordon 2018-08-06 21:20:21 UTC 
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.