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