The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I am reposting from Game Development as this is probably more suitable place:

Hi,

until now (before ios sdk 8.2) SDL_CreateWindow() with the size 1024x768 and fullscreen flag true, on Retina devices a window would be created correctly but its size would be reported (using SDL_GetWindowSize) as 2048x1536. My app would then detect this sitation and assume that scaing is necessary as getting window of requested size was not possible. Now after rebuilding HEAD against sdk 8.2 SDL_CreateWindow() returns 1024x768. Is that desired? Must I change my code now or is it a bug in HEAD?

On Wed, Apr 15, 2015 at 2:03 PM, slimshader wrote:



Hi, I believe you're supposed to call https://wiki.libsdl.org/SDL_GL_GetDrawableSize and compare that value to the window size.
So in your case the window size is 1024x768, but SDL_GL_GetDrawableSize will return 2048x1536.

Also, be sure to use the SDL_WINDOW_ALLOW_HIGHDPI flag when creating the window (note the commit message here https://hg.libsdl.org/SDL/rev/cf8fab52e33b ).

Using the combination of all that (SDL_GL_GetDrawableSize or SDL_GetRendererOutputSize, SDL_GetWindowSize, etc.) will be much more robust than hard-coding something to determine whether scaling needs to happen, as well. And it’ll work as expected on Retina displays in OS X.

On 15.04.2015 22:03, slimshader wrote:

It's inconsistent with the documentation. It's inconsistent with how
sane APIs operate. It's clearly not desired, and it's clearly a bug.

However, it is a bug that somebody intentionally introduced for
compatibility with a similar bug in the OS X code, which may also have
been intentionally introduced. Fixing it is going to be hard, not just
technically but politically. For now, it might be best not to assume
that this bug will get fixed.


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Thanks, this seems to work but I can't say that it feels right. Why would window size not be 2048 x 1536? Reported 1024x768 is nothing really. On top of that I see that mouse position coordinates are in terms of what I suppose we call drawable (so in the full range 2048x1536) which is additioanlly confusing as it means mouse/touch can be outside window (and a display)

Yup, it does not look right.

On 16.04.2015 11:04, slimshader wrote:

I recommend filing a bug report on https://bugzilla.libsdl.org/. I'd do
it myself, but I only have second-hand knowledge of this bug (i.e. no
retina device on which to test this), so my description would probably
be wrong.


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That’s because… it’s not a bug. And it’s certainly not one that needs to be fixed.

But this has been explained to you before and you refuse to listen.

I don't know if it is a bug or not but it certainly makes little sense. How can drawable be bigger than display bounds or a window? How can mouse events have positions outiside of window? If it is not a bug then it is certainly a bad design.

Window size, window position, display mode size, and mouse position are all in “points” (as iOS and OS X defines them) rather than pixels. If the mouse position isn’t in that coordinate space then there’s a bug somewhere.
SDL’s touch coordinates are always in the range of [0, 1]. On touch screen devices that’s relative to the SDL window’s position.

Here’s some more explanations:
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html

The drawable size is in pixels rather than points when high-dpi mode is enabled on a retina display. The idea is to have significantly more pixel density while taking up the exact same amount of area and with content displaying at the same sizes and relative positions as when high-dpi mode isn’t enabled.

It exists this way because it’s become standard for just about any drawing API to delineate between the logical resolution (in terms of points) and the composition/render resolution (in terms of pixels).
Given that the native frameworks of several platforms make this distinction (OS X, iOS, Android, and web - although Windows notionally does too), this is how it’s captured by SDL.

As far as what has to keep being repeated: it’s done this way to allow resolution-independent UI scaling. By targeting a logical resolution (instead of the native pixel resolution) it allows the application to draw everything as if was at the screen resolution, while the underlying API can handle the specifics of if it is being rendered at 1x the logical resolution, 2x the logical resolution, 3x the logical resolution, or some non-integer scale of it.

And maybe more to the point: you get this DPI dependent scaling effectively for free, with no additional work.

It’s important to understand the coordinate system that graphics API’s (and hardware) use to draw everything is entirely arbitrary - there is little-to-no distinction between drawing in normalized device coordinates (e.g., -1..1) and drawing in terms of points (0..1280) or drawing in terms of pixels (0..2560). This is a simple coordinate transform, and ultimately doesn’t matter at all to the size of the underlying frame buffer / texture. Not only that, but you can draw different elements in terms of different arbitrary coordinate systems into the same frame buffer. The conversion of coordinates -> pixels is handled by the hardware itself, when it is actually generating the raster image.

The only time this is not the case is if you are, like Rainer, treating the window as a giant array of pixels and want to be able to address them individually. This is, of course, the wrong way of handling of both high-resolution displays and HiDPI displays - not only does it becoming increasingly inefficient as resolutions increase, but it also fails to take into account that UI elements often need to be scaled according to the (potentially user-set, in the case of Windows) scaling factor and not just by the native resolution of the screen. Or that the native resolution of a screen might not be the size it’s rendering at either.

A case could be made on that API being non-intuitive or less than optimal, but this decision is not a bug. It’s accurately reflecting the behavior of underlying API’s and hardware - even though some people insist on writing software that ignores that.

My application was handing UI scaling on its own, it only needed actual size of the display. Just because some programmers need it handled for them does not mean it is correct. Retina display size is 2048x1536 not 1024x768. I am using pure pure OpenGL with 2D ortho projection to map coordinatesto pysical pixels. Please do not teach me about NDC because it has nothing to do with physical device size and is in fact abstract concept of graphics API. After day of work I "fixed" my application, I am only concerned for how long as SDL devs may decide that polar coordinates are better suited for this.

Don't get me wrong, I appreciate Hi DPI support it is just (imho) not handled quite properly wrt to breaking existing code and documentation isn't really that helpful.

Documentation could definitely be improved. It does change the behaviour of existing code, but only if the code doesn’t already use the proper SDL APIs (although not knowing to use those is also partially a documentation issue.)

Luke you are my new frikkin hero have a medal

For someone who claims to know all about graphics APIs you are really missing the point.
You don’t need to know the physical resolution to draw 99% of a scene. By drawing all the UI pieces in terms of an orthographic projection that uses the results of SDL_GetWindowSize (and not SDL_GL_GetDrawableSize), you can effectively treat a @2x scaled window exactly the same as if it wasn’t scaled at all - and get consistent results across all platforms, while still rendering at Retina resolution.

The only place you absolutely need to know the actual resolution is when sizing intermediate FBOs. I’m sure someone will have an edge case or two that requires them, but for the most part core OpenGL and GL ES has moved entirely away from forcing developers to deal with actual pixel size. Even line drawing - when done correctly, and not using GL_LINES - can be performed without needing to know the underlying screen resolution.

This isn’t a matter of “some programmers needing it handled for them”. It’s a matter of handling DPI scaling on your own being bad practice. When you do it yourself you totally ignore the platform (and maybe user specified) conventions for how a UI should be scaled. And that is fundamentally wrong.

These conventions are there to handle it for you - use them.

Anyways, thanks for the assistance. Patch is prepared

I am not saying it is not useful. I am saying that GetWIndowSize is suddenly returning different value and that was not expected

Yeah, this is certainly a documentation bug.  To me, the biggest problem is that the high-dpi changes introduced a break between SDL 2.0.0 and 2.0.1 since SDL_GL_GetDrawableSize() was not in 2.0.0.  Code written against (or semantics formed upon) 2.0.0 needs to be updated, but those old programs with a newer SDL dll would still be broken...

Jonny D






On Thu, Apr 16, 2015 at 4:29 PM, slimshader wrote: