(In reply to sjordan from comment #0)
>
> The correct behavior should be to wipe the scaled version because there is
> no benefit in using scaled modes over unscaled ones using SDL

The idea is that if SDL chooses a display mode capable of DPI scaling, your app can choose whether to opt into high dpi or not (using the usual SDL_WINDOW_ALLOW_HIGHDPI flag). This matches the behaviour of windowed mode, and allows the OS to properly tell the app the DPI scale factor (via SDL_GL_GetDrawableSize etc) so the app can have its UI and other elements positioned and sized correctly. If SDL prefers display modes not capable of DPI scaling, your app doesn't have as much control or understanding of how the user will expect things to be scaled.

Does macOS not optimize rendering a non-retina app to a retina-capable display mode, in fullscreen? What sort of measured performance difference is there?

Also it's worth mentioning Apple has been moving away from app-controlled exclusive fullscreen for several years now, and desktop fullscreen via Spaces seems to be what they prefer OpenGL/Metal apps to use (not to mention it's much more user-friendly), although there are still legit use cases for exclusive fullscreen of course.

I don't use SDL_WINDOW_ALLOW_HDPI and got scaled modes delivered. This mechanism appears to be non-functional for Mac which is also confirmed by a quick grep through the sources yielding only very few places where that information is used at all. 

The main problem is that SDL doesn't know the concept of scaled *display modes*. Look at SDL_DisplayMode, there is no information in there to distinguish scaled from unscaled display modes. That's the reason why SDL_AddDisplayMode() throws away display modes which aren't equivalent when considering the scaling factor. 

Thus if SDL really wants to offer the user the choice to request scaled and unscaled display modes then it should add the scaling information to SDL_DisplayMode and fix SDL_AddDisplayMode() to use it (and there are other places to fix, i.e. the code where the window is linked to an appropriate display mode depending on the high dpi flag). Additionally the cocoa driver must also be fixed to actually fetch a list of all scaled modes if that is possible. Currently the desktop mode is the only scaled mode fetched by the driver.

Alternatively, if no explicit choice shall be given to the user to select scaled or unscaled modes, then at least the behavior should be made consistent by discarding scaled modes in favor of unscaled ones if both have the same size.

To make clear how inconsistent the current behavior is let me give an example: we have opened our application with different fullscreen sizes and have made screenshots and determined the size of them. Out of the 20 sizes that we got delivered from SDL, 19 yielded screenshot sizes which were consistent with the requested size and only the size 2560x1440 yielded a 5K screenshot. The reason for this is that the SDL cocoa driver adds the desktop mode (2.5K/5K scaled) *before* it adds the unscaled ones, thus the unscaled 2.5K mode was discarded.

Let me add minor correction to my previous comment: SDL_DisplayMode does not contain the scaling information directly, but it has the 'driverdata' field, so in principle SDL_AddDisplayMode() could talk to the driver to get the scaling information.

(In reply to sjordan from comment #3)
> I don't use SDL_WINDOW_ALLOW_HDPI and got scaled modes delivered. This
> mechanism appears to be non-functional for Mac which is also confirmed by a
> quick grep through the sources yielding only very few places where that
> information is used at all. 

SDL_WINDOW_ALLOW_HIGHDPI is a flag passed to window creation used after the video mode has been set (or if exclusive fullscreen is not used at all, which is the typical case for macOS apps).
If the video mode is scaling-capable, then the highdpi flag will allow the window to use the full pixel density while keeping the units used for positioning and scaling the same. If the video mode is not scaling-capable (what you're proposing), then there would be no way for apps to opt in or out of that functionality using the highdpi flag.


> The main problem is that SDL doesn't know the concept of scaled *display
> modes*. Look at SDL_DisplayMode, there is no information in there to
> distinguish scaled from unscaled display modes. That's the reason why
> SDL_AddDisplayMode() throws away display modes which aren't equivalent when
> considering the scaling factor. 

I agree, however SDL's API and ABI aren't going to change in a breaking manner in the 2.0.x cycle. Preferring scaling-capable modes offers the most flexibility to developers while also matching what users expect more closely than the alternatives. (And again, exclusive-fullscreen is pretty miserable in macOS to begin with - users aren't able to command-tab to switch away from the app, for example.)
What sort of performance penalty numbers have you measured?


> Currently the desktop mode is the only scaled mode fetched by the
> driver.
> 
> To make clear how inconsistent the current behavior is let me give an
> example: we have opened our application with different fullscreen sizes and
> have made screenshots and determined the size of them. Out of the 20 sizes
> that we got delivered from SDL, 19 yielded screenshot sizes which were
> consistent with the requested size and only the size 2560x1440 yielded a 5K
> screenshot. The reason for this is that the SDL cocoa driver adds the
> desktop mode (2.5K/5K scaled) *before* it adds the unscaled ones, thus the
> unscaled 2.5K mode was discarded.

This is actually due to a workaround for a macOS bug (which I had forgotten about until now, heh). See here: https://bugzilla.libsdl.org/show_bug.cgi?id=3949

The Apple API to fetch scaling-capable display modes is broken in at least certain versions of macOS 10.12 (and fixed in macOS 10.13). We should be using it in 10.13+, but we aren't currently.

Thanks for your explanation, now I see why the scaled desktop mode is necessary.

We use fullscreen mode because our app is a high-fps game. I haven't measured the performance implication of rendering into a 2.5K/5K mode yet, I would expect it not to be fatal, but still not negligible when the game runs at high fps. We are generally concerned about Mac performance as it lags behind PC performance, especially in gaming, so we try hard to improve the efficiency of the Mac build.

Yes, I agree, not being able to Cmd-Tab is really bad. At least Cmd-H (minimize) seems to work.

Well, we can then conclude that enforcing unscaled modes won't be possible until the scaled display mode becomes a SDL concept. Until then we will work with our local patched version of SDL.