s/AppKite/AppKit/

My Retina MBP already reports 2880x1800 as an available mode in SDL2, and lets me SDL_CreateWindow() at that resolution...does this really not give you a 2880x1800 context?

--ryan.

I believe it does if you're using SDL_WINDOW_FULLSCREEN, Ryan, but not for SDL_WINDOW_FULLSCREEN_DESKTOP or regular windowed mode.

(In reply to comment #3)
> I believe it does if you're using SDL_WINDOW_FULLSCREEN, Ryan, but not for
> SDL_WINDOW_FULLSCREEN_DESKTOP or regular windowed mode.

Oh, hmm, good point.

--ryan.

GLFW did something very similar for its retina support: https://github.com/elmindreda/glfw/pull/36#issuecomment-18849606

I don't think it can really get much better than your implementation, given what's available in Apple's APIs.

As I mentioned on IRC, your SDL_WINDOW_ALLOW_HIGHDPI flag uses the same value as the mask used for SDL_WINDOW_FULLSCREEN_DESKTOP, so WindowFlags of (SDL_WINDOW_ALLOW_HIGHDPI | SDL_WINDOW_FULLSCREEN) have an identical value to SDL_WINDOW_FULLSCREEN_DESKTOP.


Also (mentioned on IRC as well), since the mouse coordinates in SDL_MOUSEMOTION events and SDL_GetMouseState/SDL_SetMouseState are integers, the reported mouse position will change once for every 2 real pixels moved in 2x scale highdpi. I discovered that the cursor seems to do this all the time anyway in a retina resolution in OS X, so at least on OS X it's probably not something that can be fixed even with API/ABI changes to SDL.

Created attachment 1242 [details]
Alternate HIDPI support proposal.

My current HIDPI proposal for SDL2..

(not completely finished as it doesn't do any changes to the Renderer APIs yet to support it)


Note that there are some issues that SDL2 in general isn't handling well with this..  Not sure if your patch handles it or not..   But a regular fullscreen mode fails horribly (mode switch) and renders nothing..  and popping back out of fullscreen mode (mode switch) causes the window rendering to be "off" until the window is moved..  (not sure why).

A couple of other things that we need to make sure are handled somehow..   If the user changes their desktop mode to a non-retina resolution the running SDL2 window will "lose" the retina backing.. that needs to be somehow handled and an event somehow sent.

Also, if a user has dual monitors (one retina and one not retina) when they "move" between the monitors the retina backing will turn on and off.  Thus the backing store size changes as well..

It's a very "fun" thing to get working 'Cleanly'.

High Resolution Guidelines for OS X:
https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html

Writing High-DPI Win32 Applications:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660.aspx

Edward, do you have any specific reasons to prefer your patch's approach over mine?

not necessarily..   I wonder why we need the hint AND the flag?  wouldn't just hte SDL_WINDOW_HIDPI flag suffice to request HiDPI?  I do prefer my shorter Window flag name though:) Mainly because it's shorter.. 

The other main thing we need to decide on is exactly HOW we want to get the scaling factor..  e.g. my patch uses GetWindowScale vs your GetDrawableSize.

I know the Apple docs are VERY adamant about always request the API to "Scale" your points (bounds, mouse cursor points etc..)..  thus leaning more toward GetDrawableSize being more "correct".   Though should we also have a "scale point" type method to adjust some window relative point to the drawable scale?

Also, have you experienced the oddities I documented with my patch?  (I'll be getting back to work on this next week and will try out your patch over mine to see if I can recreate them).

I need to sift through MS's docs and see how their philosophy differs from apple's.

The hint *and* the flag was because people upgrading to newer SDLs might not do the required changes to their glViewport etc calls, and still call SDL_GetWindowSize. This means it's guaranteed to not work until the developer has done the work to support retina.

The hint is to disable retina support, since the developer might enable retina support without having a way of turning it off -- and if that causes performance to be too poor for the end-user, they can force it off (or for the developer to test on lower resolutions).

I personally like us returning the size of the drawable, since that deals with rounding and other weirdness consistently when it comes to non-2.0 scaling factors. The APIs you're passing these values to don't understand floating point, so it should be integer values anyway.

I never tried any of the things that'll cause a retina window to drop down to non-retina runtime. I'm guessing I probably have the same issues you do - but I'd hope we get a "resize" event from the OS when that happens, so we can call glViewport with the new SDL_GetDrawableSize? Have you seen any docs from Apple on how to best handle this when you have an NSOpenGLView/Context?

I haven't done any more work on my patch, since I decided to postpone the work to add retina support to Dota 2 for the time being (due to the required amount of digging around inside the guts of the engine).

those are some good points..  And yes I did read some docs about how to handle those in apple's docs..  I'll have to dig them up again.. it's been a few weeks since I last played with this..    I had switched focus on that project to getting it ported to from SDL 1.2 to SDL2 and ran into some new issues with touch input and mouse wheel scrolling stuff that I need to push out fixes for first.

I'll post any new docs/updates here though..  so we can figure out the best solution.

(In reply to comment #2)
> My Retina MBP already reports 2880x1800 as an available mode in SDL2, and
> lets me SDL_CreateWindow() at that resolution...does this really not give
> you a 2880x1800 context?
> 
> --ryan.

Also, when you consider using things like Gamecenter integration you really want to be in a "retina" resolution if you want the hidpi otherwise the overlayed GC UI will appear "very tiny" and the native 2880x1800 resolution...

Retina just makes things "Oh so fun".

Tangentially related it would be nice to have an API to get the physical screen dpi. See e.g. 

http://stackoverflow.com/questions/2621439/how-to-get-screen-dpi-linux-mac-programatically

Created attachment 1333 [details]
Updated patch based on Jørgen's patch

This is a rebased patch against tip with a few fixes..


First use a different enum value for the ALLOW_HIGHDPI flag so it doesn't collide with FULLSCREEN_DESKTOP

Second, remove need for extra state variable when the flags can be used..

This looks good, thanks guys!

Can one of you add the appropriate documentation to the SDL wiki?