SDL_GetWindowSize behaviour change in iOS 8.2 |
SDL_GetWindowSize behaviour change in iOS 8.2 |
eric.w
|
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. |
|||||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Alex Szpakowski
Guest
|
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.
|
|||||||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Rainer Deyke
Guest
|
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 |
|||||||||||||
|
Re: SDL_GetWindowSize behaviour change in iOS 8.2 |
slimshader
|
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) |
|||||||||||||||||
|
Re: SDL_GetWindowSize behaviour change in iOS 8.2 |
slimshader
|
Yup, it does not look right. |
|||||||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Rainer Deyke
Guest
|
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 |
|||||||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Luke Groeninger
Guest
|
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.
|
|||||||||||||
|
Re: SDL_GetWindowSize behaviour change in iOS 8.2 |
slimshader
|
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. |
|||||||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Alex Szpakowski
Guest
|
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.
|
|||||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Luke Groeninger
Guest
|
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.
|
|||||||||||||
|
Re: SDL_GetWindowSize behaviour change in iOS 8.2 |
slimshader
|
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. |
|||||||||||||||
|
Re: SDL_GetWindowSize behaviour change in iOS 8.2 |
slimshader
|
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. |
|||||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Alex Szpakowski
Guest
|
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.)
|
|||||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Neil White
Guest
|
Luke you are my new frikkin hero have a medal
|
|||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Luke Groeninger
Guest
|
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.
|
|||||||||||||
|
Re: SDL_GetWindowSize behaviour change in iOS 8.2 |
slimshader
|
Anyways, thanks for the assistance. Patch is prepared |
|||||||||||||||
|
Re: SDL_GetWindowSize behaviour change in iOS 8.2 |
slimshader
|
I am not saying it is not useful. I am saying that GetWIndowSize is suddenly returning different value and that was not expected |
|||||||||||||||
|
SDL_GetWindowSize behaviour change in iOS 8.2 |
Jonny D
|
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:
|
|||||||||||||
|