SDL_GetWindowSize behaviour change in iOS 8.2

SDL Development
1

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?

2

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?

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.On Wed, Apr 15, 2015 at 2:03 PM, slimshader <szymon.gatner at gmail.com> wrote:

3

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 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 Apr 15, 2015, at 5:29 PM, Eric Wasylishen wrote:

On Wed, Apr 15, 2015 at 2:03 PM, slimshader <szymon.gatner at gmail.com <mailto:szymon.gatner at gmail.com>> wrote:
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?

Hi, I believe you’re supposed to call https://wiki.libsdl.org/SDL_GL_GetDrawableSize 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 mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

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.On 15.04.2015 22:03, slimshader wrote:

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?

–
Rainer Deyke (rainerd at eldwood.com)

5

Alex Szpakowski wrote:

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 (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.

  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?

Hi, I believe you’re supposed to call https://wiki.libsdl.org/SDL_GL_GetDrawableSize (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 mailing listSDL at lists.libsdl.org (SDL at lists.libsdl.org)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)> > On Apr 15, 2015, at 5:29 PM, Eric Wasylishen <ewasylishen at gmail.com (ewasylishen at gmail.com)> wrote:

On Wed, Apr 15, 2015 at 2:03 PM, slimshader <@slimshader (@slimshader)> wrote:

6

Rainer Deyke wrote:> On 15.04.2015 22:03, slimshader wrote:

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?

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 (rainerd at eldwood.com)

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yup, it does not look right.

7

Rainer Deyke wrote:

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.

Yup, it does not look right.

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.On 16.04.2015 11:04, slimshader wrote:

On 15.04.2015 22:03, slimshader wrote:

–
Rainer Deyke (rainerd at eldwood.com)

8

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.> On Apr 15, 2015, at 11:49 PM, Rainer Deyke wrote:

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.

9

Luke Groeninger wrote:

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.

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.

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.> > On Apr 15, 2015, at 11:49 PM, Rainer Deyke <rainerd at eldwood.com (rainerd at eldwood.com)> wrote:

10

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/Introduction/Introduction.html
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.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.> On Apr 16, 2015, at 6:03 AM, slimshader <szymon.gatner at gmail.com> wrote:

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)

11

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.> On Apr 16, 2015, at 9:27 AM, slimshader <szymon.gatner at gmail.com> wrote:

Luke Groeninger wrote:
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.

Quote:
On Apr 15, 2015, at 11:49 PM, Rainer Deyke <> wrote:
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.

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 mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

12

Luke Groeninger wrote:

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.

Luke Groeninger wrote: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.Quote:On Apr 15, 2015, at 11:49 PM, Rainer Deyke <> wrote: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.

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 mailing listSDL at lists.libsdl.org (SDL at lists.libsdl.org)http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org (http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

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.> > On Apr 16, 2015, at 9:27 AM, slimshader <@slimshader (@slimshader)> wrote:

13

slimshader wrote:

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.

14

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.)> On Apr 16, 2015, at 1:16 PM, slimshader <szymon.gatner at gmail.com> wrote:

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.

15

Luke you are my new frikkin hero have a medal

16

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.> On Apr 16, 2015, at 10:10 AM, slimshader <szymon.gatner at gmail.com> wrote:

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.

17

Alex Szpakowski wrote:

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.)

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.

Anyways, thanks for the assistance. Patch is prepared :)> > On Apr 16, 2015, at 1:16 PM, slimshader <@slimshader (@slimshader)> wrote:

18

Luke Groeninger wrote:

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.

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.

I am not saying it is not useful. I am saying that GetWIndowSize is suddenly returning different value and that was not expected> > On Apr 16, 2015, at 10:10 AM, slimshader <@slimshader (@slimshader)> wrote:

19

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 DOn Thu, Apr 16, 2015 at 4:29 PM, slimshader <szymon.gatner at gmail.com> wrote:

Luke Groeninger wrote:

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.

Quote:

On Apr 16, 2015, at 10:10 AM, slimshader <> wrote:
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.

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

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org