And to add to this: on Windows not only the setting is specified by
the user (so there isn’t a range of choices to select from), the
scaling factor can be non-integer. Enjoy dealing with that.
2014-12-02 17:30 GMT-03:00, Eirik Byrkjeflot Anonsen :> It sounds like you don’t understand what the high-dpi flag means (or
“dpi aware” as windows calls it, I believe). When an application
requests the high-dpi mode it is promising that it will adjust its
display according to the actual resolution of the screen rather than
assuming it is 72 or 96 dpi. If the application does not make this
promise, chances are it has designed its UI elements to have a sensible
size at 72 or 96 dpi. You can imagine what that does to usability at
much higher resolutions.
So yes, it is a binary switch: Either you deal correctly with
high-resolution modes, or you don’t. If you want specific scaling
factors, you’ll have to handle it yourself. If you want full access to
the physical pixels, enable high-dpi mode. If you just want to be able
to continue drawing stuff as if all screens are roughly the same old
resolution, keep the high-dpi mode off and things will keep working as
expected.
In short: non-high-dpi mode is a compatibility trick to make typical
applications work well with high-resolution screens. It is not a feature
to request automatic scaling of graphics.
That should be the default. It’s completely insane that this isn’t the
default. When I ask SDL for a 4000x3000 window, I want exactly
4000x3000 actual physical pixels.
And we give you a way to get that.
written before high-dpi was a thing. I want to be able to run the game
at its full resolution without having to code around the insanity of the
modern operating systems.
Adding an extra flag to a single function call isn’t what I would call
"coding around."
Also, on Mac OS X, enumerating display modes will list the retina
resolution (2800x1800), and if you set fullscreen to that, you’ll get
it, flag or not.
which is likely to be an odd number. For a game written for arbitrary
resolutions, I want to give the user full control over the scaling
factor so that she can choose the best trade-off between resolution and
performance. In no case does the operating system’s default scaling
factor even influence my choice.
Cool, add the flag and don’t use the OS’s default scaling factor.
Desktop dpi varies a lot more than that. You can’t assume any
particular dpi or dpi range, with or without high-dpi mode.On 02.12.2014 21:30, Eirik Byrkjeflot Anonsen wrote:
It sounds like you don’t understand what the high-dpi flag means (or
"dpi aware" as windows calls it, I believe). When an application
requests the high-dpi mode it is promising that it will adjust its
display according to the actual resolution of the screen rather than
assuming it is 72 or 96 dpi. If the application does not make this
promise, chances are it has designed its UI elements to have a sensible
size at 72 or 96 dpi. You can imagine what that does to usability at
much higher resolutions.
That should be the default. It’s completely insane that this isn’t the
default. When I ask SDL for a 4000x3000 window, I want exactly
4000x3000 actual physical pixels.
And we give you a way to get that.
So, I request a 4000x3000 high-dpi window. Do I actually get 4000x3000
pixels, and not 4000x3000x? Do
SDL_GetDesktopDisplayMode, SDL_GetWindowSize, and SDL_MOUSEMOTION report
actual physical pixels? I have no complaint in case of the former, but
this indicates the latter:On 02.12.2014 22:26, Ryan C. Gordon wrote:
On 01.12.2014 03:22, Alex Szpakowski wrote:
I haven?t changed any public SDL APIs compared to the current SDL
2.0.4 / mercurial version. The biggest non-bugfix change to
functionality is that SDL_CreateWindow now only enables
Retina-resolution if the SDL_WINDOW_ALLOW_HIGHDPI flag is used, and
once it?s enabled you?ll need to use SDL_GL_GetDrawableSize (or
SDL_GetRendererOutputSize if you?re using the SDL_Render API) to get
the size of the drawable in pixels. SDL_GetWindowSize and the active
video display modes now always give their sizes in ?points? rather
than pixels.
Rainer Deyke writes:> On 02.12.2014 21:30, Eirik Byrkjeflot Anonsen wrote:
It sounds like you don’t understand what the high-dpi flag means (or
"dpi aware" as windows calls it, I believe). When an application
requests the high-dpi mode it is promising that it will adjust its
display according to the actual resolution of the screen rather than
assuming it is 72 or 96 dpi. If the application does not make this
promise, chances are it has designed its UI elements to have a sensible
size at 72 or 96 dpi. You can imagine what that does to usability at
much higher resolutions.
Desktop dpi varies a lot more than that. You can’t assume any
particular dpi or dpi range, with or without high-dpi mode.
The actual resolution of physical monitors have of course varied a bit.
But not more than that the vast majority of applications have in fact
assumed a narrow dpi range. The high-dpi mode (when not enabled)
provides compatibility behaviour for those applications.
The main exceptions to the standard dpi range has been people with less
than stellar eyesight choosing a low pixel count as a way to scale all
graphics to make them more readable. A trick that worked precisely
because most applications assumed a narrow dpi range.
The actual resolution of physical monitors have of course varied a bit.
But not more than that the vast majority of applications have in fact
assumed a narrow dpi range. The high-dpi mode (when not enabled)
provides compatibility behaviour for those applications.
The main exceptions to the standard dpi range has been people with less
than stellar eyesight choosing a low pixel count as a way to scale all
graphics to make them more readable. A trick that worked precisely
because most applications assumed a narrow dpi range.
The mere fact it can still vary a lot means we should support it.
Also: monitors can report their physical size. What will happen when
operating systems start to rely on that to adapt the DPI on the fly
based on the physical size and the resolution?