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.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
High dpi, was Re: IOS 8 progress
Rainer Deyke
Guest

On 01.12.2014 10:01, Alex Szpakowski wrote:
Quote:
- It matches SDL’s behaviour in OS X (and presumably Windows and
Linux, once high-dpi support is implemented in those backends.)

Quote:
- It lets you render at a high resolution while keeping the physical
size of what you render consistent with what users expect on their
device. In other words you can easily use the “dpi scale” of the
device. This is actually really useful.

Quote:
- You can save performance on older / lower-end retina iOS devices by
disabling high-dpi awareness at runtime. If you’re using everything
correctly, doing so will just make things look a bit less sharp to
users while saving a ton of memory and GPU pixel processing
performance.

Quote:
There was some discussion about what SDL’s high-dpi API would be, a
year or so ago: https://bugzilla.libsdl.org/show_bug.cgi?id=1934

(Not directed to you in particular.) Sorry, but that's terrible, and
Bugzilla is a terrible place for these kinds of discussions. There are
two use cases for SDL:

- I have a game that runs at a fixed resolution. In that case, I
only care about the logical resolution of the game, i.e. the size of the
backing store. Suppose I request a 4000x3000 window. I don't care if
this is a full 4096x3072 screen or a 8192x6144 screen scaled up x2 or a
16384x12288 screen scaled up x4 or even a 1280x1024 screen scaled down
x0.25.

- I have a game that runs at an arbitrary resolution. In that case I
am already taking responsibility for scaling on my end, so I just want
the biggest, most high-dpi window that I can get.

In addition, the high-dpi API has the following flaws:

- It treats high-dpi as a binary switch: either you have it or you
don't. Suppose I had a device with a logical resolution of 320x200 and
a physical resolution of 1280x800. I would now be able to request
either a 320x200 window (scaled x4) or a 1280x800 window (scaled x1),
but not an intermediate 640x480 window (scaled x2).

- I have to call SDL_GL_GetDrawableSize to get the real size of the
back buffer even though I may not be using the OpenGL API (or even an
OpenGL backend).

- It is basically undocumented.

Now, to address your points one by one:

Quote:
- It matches SDL’s behaviour in OS X (and presumably Windows and
Linux, once high-dpi support is implemented in those backends.)

Consistency is good, but I *really* hope the high-dpi API gets
fixed/replaced/ditched before it becomes too entrenched to change.

Quote:
- It lets you render at a high resolution while keeping the physical
size of what you render consistent with what users expect on their
device. In other words you can easily use the “dpi scale” of the
device. This is actually really useful.

This would be a valid argument if the "logical pixel" size were
consistent between devices. On PCs, the "logical resolution" can vary
from 640x480 to well over twice, all without "high-dpi" mode, and that's
not even taking into account the different monitor sizes. And mobile
ports of the PC game.

If you really want to do this, a SDL_GetDPIScale function would work better.

Quote:
- You can save performance on older / lower-end retina iOS devices by
disabling high-dpi awareness at runtime. If you’re using everything
correctly, doing so will just make things look a bit less sharp to
users while saving a ton of memory and GPU pixel processing
performance.

That's an argument in favor of adding arbitrary up-scaling to SDL, not
the current high-dpi API. For example, I have a PC game that runs at
640x480. If the screen resolution is at least 1280x960, I want to scale
the game up x2. However, 1280x960 is not considered a high-dpi
resolution on PCs, so high-dpi scaling is useless to me. If I want to
run the same game on an iPhone 4+, I need to suddenly need to use the
high-dpi API in SDL because my base resolution of 640x480 is a high-dpi
resolution on iPhones.

Here is what my code would have to look like under the current API:

if desired_resolution >= desktop_resolution:
window_size = desired_resolution / 2
create_window(window_size)
actual_resolution = SDL_GL_GetDrawableSize()
scale_factor = actual_resolution / window_size
if scale_factor != 2:
close_window()
window_size = desired_resolution / scale_factor
create_window(window_size)
else:
scale_factor = desktop_resolution / desired_resolution
create_window(window_size * scale_factor)
actual_resolution = SDL_GL_GetDrawableSize()
scale_factor = actual_resolution / desired_resolution
proceed_to_run_game_at(scale_factor)

...and even that doesn't handle all of the edge cases. Here is what my
code should look like:

scale_factor = desktop_resolution / desired_resolution
create_window(desired_resolution, scale_factor)
proceed_to_run_game_without_caring_about_scaling()


(Also, if you want to go to a lower resolution to save performance, you
should really also load your textures at a lower resolution. It's not
as simple as flipping a high-dpi switch.)


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Alex Szpakowski
Guest

Quote:
There are two use cases for SDL: [..]

FWIW there are many more use cases. For many people SDL is just used as an API to abstract windowing and input across multiple platforms. Since this is a feature of OS windowing APIs, it makes sense to expose it in an abstracted manner.

Quote:

In addition, the high-dpi API has the following flaws:

- It treats high-dpi as a binary switch: either you have it or you don't. Suppose I had a device with a logical resolution of 320x200 and a physical resolution of 1280x800. I would now be able to request either a 320x200 window (scaled x4) or a 1280x800 window (scaled x1), but not an intermediate 640x480 window (scaled x2).

I think you’re misunderstanding the purpose of the operating system-level high-DPI scaling (which this is.) In OS X it *is* a binary switch that apps do have to opt-in to get. On iOS it’s essentially a binary switch as well (if you want the OS to use the fast path for compositing when high-dpi mode is enabled.)

Apple’s documentation elaborates:
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html

Quote:

- I have to call SDL_GL_GetDrawableSize to get the real size of the back buffer even though I may not be using the OpenGL API (or even an OpenGL backend).

You can use SDL_GetRendererOutputSize if you’re using the SDL_Render API. If you aren’t using SDL_GL or SDL_Render at all then there should be no issue, since those are the only ways that SDL exposes a graphics drawable that can have high-dpi mode enabled.

Quote:
Quote:
- It lets you render at a high resolution while keeping the physical
size of what you render consistent with what users expect on their
device. In other words you can easily use the “dpi scale” of the
device. This is actually really useful.

This would be a valid argument if the "logical pixel" size were consistent between devices. On PCs, the "logical resolution" can vary from 640x480 to well over twice, all without "high-dpi" mode, and that's not even taking into account the different monitor sizes. And mobile ports of the PC game.

A major reason that the operating system APIs let you toggle high-dpi mode and convert between coordinate spaces is that it’s specifically designed to make things a higher resolution and pixel density while keeping the same “logical” scale as you would have if high-dpi were disabled. A major reason for disabling it is that, for games in particular, the number of pixels to process and the memory usage of buffers and textures can simply be too high on some systems.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Sik


Joined: 26 Nov 2011
Posts: 905
I think the actual real problem in this discussion is that we keep
talking about like we're using pixels when these days operating
systems don't do that anymore (and SDL2 fails to reflect this).

That said, I guess it'd be nice to get an easy way to get a window
size *in pixels* before even creating one, just for the sake of being
able to implement a resolution list. But I suppose that people will
argue that in fullscreen you should use the native resolution, and
that in windowed there isn't any reason to restrict to arbitrary sizes
(it still screws up if you want to allow only integer-sized scaling,
i.e. if the program uses pixelart).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Rainer Deyke
Guest

On 01.12.2014 12:15, Alex Szpakowski wrote:
Quote:

Quote:
There are two use cases for SDL: [..]

FWIW there are many more use cases. For many people SDL is just used
as an API to abstract windowing and input across multiple platforms.

Yeah, but pretty much all of them fit either into the "fixed resolution"
or the "variable resolution" camps.

Quote:
Quote:
In addition, the high-dpi API has the following flaws:

- It treats high-dpi as a binary switch: either you have it or you
don't. Suppose I had a device with a logical resolution of 320x200
and a physical resolution of 1280x800. I would now be able to
request either a 320x200 window (scaled x4) or a 1280x800 window
(scaled x1), but not an intermediate 640x480 window (scaled x2).

I think you’re misunderstanding the purpose of the operating
system-level high-DPI scaling (which this is.) In OS X it *is* a
binary switch that apps do have to opt-in to get. On iOS it’s
essentially a binary switch as well (if you want the OS to use the
fast path for compositing when high-dpi mode is enabled.)

Yes, right now under these particular operating systems that's the case,
but Apple has never been particularly good about forward and backward
compatibility. So what happens if Apple decides that the iPhone 10 need
a 652 dpi "double retina" screen? Suddenly your binary switch has three
possible states. What happens when you port your game from mobile to
Mac and your high-dpi game is now restricted to a tiny window on a huge
5120x2880 screen? What happens when a random future operating system
decides that "high-dpi" has not twice but three times the base resolution?

IMO, the purpose of SDL is to isolate the programmer from these kinds of
low-level details.

Quote:
Quote:
- I have to call SDL_GL_GetDrawableSize to get the real size of the
back buffer even though I may not be using the OpenGL API (or even
an OpenGL backend).

You can use SDL_GetRendererOutputSize if you’re using the SDL_Render
API. If you aren’t using SDL_GL or SDL_Render at all then there
should be no issue, since those are the only ways that SDL exposes a
graphics drawable that can have high-dpi mode enabled.

There's also SDL_GetWindowSurface, although that carries the screen
resolution along with it. That's two-and-a-half different functions for
getting the same information.


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Re: High dpi, was Re: IOS 8 progress
RodrigoCard


Joined: 23 Apr 2011
Posts: 113
Location: Brazil
Rainer Deyke wrote:
On 01.12.2014 12:15, Alex Szpakowski wrote:
Yes, right now under these particular operating systems that's the case,
but Apple has never been particularly good about forward and backward
compatibility. So what happens if Apple decides that the iPhone 10 need
a 652 dpi "double retina" screen? Suddenly your binary switch has three
possible states. What happens when you port your game from mobile to
Mac and your high-dpi game is now restricted to a tiny window on a huge
5120x2880 screen? What happens when a random future operating system
decides that "high-dpi" has not twice but three times the base resolution?

IMO, the purpose of SDL is to isolate the programmer from these kinds of
low-level details.
---
Rainer Deyke


Yeah, the current way SDL handles the contentscale factor breaks each time Apple updates iOS, is doesnt seem very future proof.
High dpi, was Re: IOS 8 progress
Alex Szpakowski
Guest

On Dec 1, 2014, at 11:25 AM, Rainer Deyke wrote:

Quote:
Yes, right now under these particular operating systems that's the case, but Apple has never been particularly good about forward and backward compatibility. So what happens if Apple decides that the iPhone 10 need a 652 dpi "double retina" screen? Suddenly your binary switch has three possible states. What happens when you port your game from mobile to Mac and your high-dpi game is now restricted to a tiny window on a huge 5120x2880 screen? What happens when a random future operating system decides that "high-dpi" has not twice but three times the base resolution?

IMO, the purpose of SDL is to isolate the programmer from these kinds of low-level details.

The iPhone 6 Plus has a “3x” Retina display. The SDL (and iOS) API handles it with no problem. You aren’t expected to hard-code 2x scale into your app – in fact, the high-DPI APIs make it easier to avoid hard-coding that kind of thing.

Again, one of the main purposes of SDL is to provide a single API that covers the useful functionality of the windowing APIs it supports.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Alex Szpakowski
Guest

Well, speaking from experience SDL’s code for handling the content scale factor has needed updating much less than almost every other part of the UIKit backend code… rotation/orientation changes, deprecated frameworks (e.g. UIAccelerometer versus CoreMotion), launch screen changes, and interface API changes like the code for determining status bar visibility have all been much bigger issues in the codebase.


In fact, SDL’s code for handling the content scale factor hasn’t needed updating at all, aside from adding support for the new ‘native scale’ so that the iPhone 6 Plus uses a pixel-perfect 1080x1920 rather than downscaled 1242x2208. The other changes I made to that area of the code were to make it behave the same way as SDL on OS X does.

On Dec 1, 2014, at 2:16 PM, RodrigoCard wrote:

Quote:
Yeah, the current way SDL handles the contentscale factor breaks each time Apple updates iOS, is doesnt seem very future proof.

Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Alex Szpakowski
Guest

I think that would be useful, yeah. Maybe the API could be something like: SDL_GetDisplayModePixelSize(const SDL_DisplayMode *mode, int *w, int *h) (maybe with a better function name.)

On Dec 1, 2014, at 12:00 PM, Sik the hedgehog wrote:

Quote:
That said, I guess it'd be nice to get an easy way to get a window
size *in pixels* before even creating one, just for the sake of being
able to implement a resolution list. But I suppose that people will
argue that in fullscreen you should use the native resolution, and
that in windowed there isn't any reason to restrict to arbitrary sizes
(it still screws up if you want to allow only integer-sized scaling,
i.e. if the program uses pixelart).
_______________________________________________
SDL mailing list

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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Alexander Chaliovski
Guest

Why not just to specify if you want 1:1 resolution versus content-scale factor ? If you want content-scale factor just specify the factor .


On Mon, Dec 1, 2014 at 9:21 PM, Alex Szpakowski wrote:
Quote:
I think that would be useful, yeah. Maybe the API could be something like: SDL_GetDisplayModePixelSize(const SDL_DisplayMode *mode, int *w, int *h) (maybe with a better function name.)

On Dec 1, 2014, at 12:00 PM, Sik the hedgehog wrote:

Quote:
That said, I guess it'd be nice to get an easy way to get a window
size *in pixels* before even creating one, just for the sake of being
able to implement a resolution list. But I suppose that people will
argue that in fullscreen you should use the native resolution, and
that in windowed there isn't any reason to restrict to arbitrary sizes
(it still screws up if you want to allow only integer-sized scaling,
i.e. if the program uses pixelart).
_______________________________________________
SDL mailing list

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

_______________________________________________
SDL mailing list

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


High dpi, was Re: IOS 8 progress
Alex Szpakowski
Guest

That’s what the SDL_WINDOW_ALLOW_HIGHDPI flag does (on platforms where it’s implemented.) It can still be useful to know if a display mode on a monitor supports that in the first place before that display mode is used or a window is created, though.

On Dec 1, 2014, at 6:36 PM, Alexander Chaliovski wrote:

Quote:
Why not just to specify if you want 1:1 resolution versus content-scale factor ? If you want content-scale factor just specify the factor .
_______________________________________________
SDL mailing list

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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Ryan C. Gordon
Guest

Quote:
- It treats high-dpi as a binary switch: either you have it or you
don't. Suppose I had a device with a logical resolution of 320x200 and
a physical resolution of 1280x800. I would now be able to request
either a 320x200 window (scaled x4) or a 1280x800 window (scaled x1),
but not an intermediate 640x480 window (scaled x2).

I think that flag is (and has always been) very misunderstood.

It basically says "give me all the pixels the hardware has, not what the
OS is telling apps it has while actually scaling them," and we have
other APIs that let you get the finer details if you want them. The
original intention was to deal with Mac OS X setting the desktop on
Retina MacBooks to 1440x900 when the hardware was capable of 2880x1800.

The API doesn't care anything about how much you are scaling, it's just
designed to prevent you from being locked out of real physical pixels if
you want them (not all apps do!), which was a real problem for
FULLSCREEN_DESKTOP apps.

Quote:
- I have to call SDL_GL_GetDrawableSize to get the real size of the
back buffer even though I may not be using the OpenGL API (or even an
OpenGL backend).

That's a solvable problem.

Quote:
- It is basically undocumented.

That's _definitely_ a solvable problem.

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Rainer Deyke
Guest

On 01.12.2014 23:38, Alex Szpakowski wrote:
Quote:
That’s what the SDL_WINDOW_ALLOW_HIGHDPI flag does (on platforms
where it’s implemented.) It can still be useful to know if a display
mode on a monitor supports that in the first place before that
display mode is used or a window is created, though.

On Dec 1, 2014, at 6:36 PM, Alexander Chaliovski
wrote:

Quote:
Why not just to specify if you want 1:1 resolution versus
content-scale factor ? If you want content-scale factor just
specify the factor .

No, it doesn't. SDL_WINDOW_ALLOW_HIGHDPI implements a fixed,
platform-dependent scaling factor. What I want is an arbitrary scaling
factor, specified by the user, implemented in a platform-independent manner.


--
Rainer Deyke
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Rainer Deyke
Guest

On 02.12.2014 07:44, Ryan C. Gordon wrote:
Quote:

Quote:
- It treats high-dpi as a binary switch: either you have it or you
don't. Suppose I had a device with a logical resolution of 320x200 and
a physical resolution of 1280x800. I would now be able to request
either a 320x200 window (scaled x4) or a 1280x800 window (scaled x1),
but not an intermediate 640x480 window (scaled x2).

I think that flag is (and has always been) very misunderstood.

No, I understand it all right. I just think it's crap.

Quote:
It basically says "give me all the pixels the hardware has, not what the
OS is telling apps it has while actually scaling them," and we have
other APIs that let you get the finer details if you want them.

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. When I ask SDL for the desktop
resolution, I want it in actual physical pixels. When I read mouse
movement events, I want them in actual physical pixels. I have a
14-year-old multiple-fixed-resolution game that supports 2560x1920,
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.

Quote:
The API doesn't care anything about how much you are scaling, it's just
designed to prevent you from being locked out of real physical pixels if
you want them (not all apps do!),

Yes, automatic scaling is a useful feature, but that has nothing to do
with high-dpi modes. It's a useful feature that 4096x2160 physical
pixels, it's a useful feature at 1280x1024 physical pixels, it's even a
useful feature at 320x200 physical pixels. Moreover, the scaling factor
I want to use is completely independent from the scaling factor that the
operating system wants me to use. For a game written for a fixed
resolution, I want the highest scaling factor that fits on the screen,
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.


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Eirik Byrkjeflot Anonsen
Guest

Rainer Deyke writes:

Quote:
On 02.12.2014 07:44, Ryan C. Gordon wrote:
Quote:

Quote:
- It treats high-dpi as a binary switch: either you have it or you
don't. Suppose I had a device with a logical resolution of 320x200 and
a physical resolution of 1280x800. I would now be able to request
either a 320x200 window (scaled x4) or a 1280x800 window (scaled x1),
but not an intermediate 640x480 window (scaled x2).

I think that flag is (and has always been) very misunderstood.

No, I understand it all right. I just think it's crap.

[...]
Quote:
Quote:
The API doesn't care anything about how much you are scaling, it's just
designed to prevent you from being locked out of real physical pixels if
you want them (not all apps do!),

Yes, automatic scaling is a useful feature, but that has nothing to do
with high-dpi modes. It's a useful feature that 4096x2160 physical
pixels, it's a useful feature at 1280x1024 physical pixels, it's even a
useful feature at 320x200 physical pixels. Moreover, the scaling factor
I want to use is completely independent from the scaling factor that the
operating system wants me to use. For a game written for a fixed
resolution, I want the highest scaling factor that fits on the screen,
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.

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.

eirik
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Sik


Joined: 26 Nov 2011
Posts: 905
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:
Quote:
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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Ryan C. Gordon
Guest

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

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

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

--ryan.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Rainer Deyke
Guest

On 02.12.2014 21:30, Eirik Byrkjeflot Anonsen wrote:
Quote:
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.


--
Rainer Deyke

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Rainer Deyke
Guest

On 02.12.2014 22:26, Ryan C. Gordon wrote:
Quote:

Quote:
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<unpredictable scaling factor>? 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 01.12.2014 03:22, Alex Szpakowski wrote:
Quote:
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
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Eirik Byrkjeflot Anonsen
Guest

Rainer Deyke writes:

Quote:
On 02.12.2014 21:30, Eirik Byrkjeflot Anonsen wrote:
Quote:
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.

eirik
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Sik


Joined: 26 Nov 2011
Posts: 905
2014-12-03 13:59 GMT-03:00, Eirik Byrkjeflot Anonsen:
Quote:
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?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
eric.w


Joined: 12 Feb 2014
Posts: 38
Bit of a tangent regarding Windows:

Quote:
Quote:
- It matches SDL’s behaviour in OS X (and presumably Windows and
Linux, once high-dpi support is implemented in those backends.)

Consistency is good, but I *really* hope the high-dpi API gets
fixed/replaced/ditched before it becomes too entrenched to change.

One potential issue for implementing high-dpi support for the Windows
backend: the API for opting out of OS-provided scaling
(SetProcessDPIAwareness) is something you can only call once, and
affects all windows for the entire lifetime of the application. [1]
This clashes with SDL_WINDOW_ALLOW_HIGHDPI being a per-window flag.


[1]. docs on the high-dpi support in Windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Rainer Deyke
Guest

On 07.12.2014 08:22, Eric Wasylishen wrote:
Quote:
Bit of a tangent regarding Windows:

Quote:
Quote:
- It matches SDL’s behaviour in OS X (and presumably Windows and
Linux, once high-dpi support is implemented in those backends.)

Consistency is good, but I *really* hope the high-dpi API gets
fixed/replaced/ditched before it becomes too entrenched to change.

One potential issue for implementing high-dpi support for the Windows
backend: the API for opting out of OS-provided scaling
(SetProcessDPIAwareness) is something you can only call once, and
affects all windows for the entire lifetime of the application. [1]
This clashes with SDL_WINDOW_ALLOW_HIGHDPI being a per-window flag.

That's arguably a good thing. If your application is dpi-aware, you
generally want all coordinates in unscaled raw physical pixels,
including e.g. SDL_GetDesktopResolution. If you want OS-provided
scaling, then you might also want SDL_GetDesktopResolution to be scaled.
My arguments against ever using OS-provided scaling still apply, but
if SDL really does want to provide access to the OS-provided scaling,
then a global flag is probably the way to go.


--
Rainer Deyke

_______________________________________________
SDL mailing list

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


Joined: 28 Nov 2013
Posts: 18
I agree that the current iOS high DPI flag is a terrible solution (from both Apple and SDL).

What we really need is the possibility to first query the actual device fullscreen resolution and then when creating the window, ability to provide the actual resolution that will be used for the backbuffer. Both iOS and android can still scale that custom size to fullscreen (somewhat) automatically and I would assume the performance would be the same as with the scaling that happens with the current iOS high DPI flag.

There are at least two good reasons to allow defining a custom backbuffer size (effectively the "screen size" from SDL apps perspective): games using a fixed resolution and 3d games that cannot afford to run on the full (sometimes massive) resolution that some devices have. Using some kind of scale multiplier or binary flag here is NOT a good solution. Currently if you are using just OpenGL for rendering. You are basically restricted to native resolution on android and a couple of fixed options on iOS (You could implement rendering to texture, but that would just waste time and memory and add complexity when SDL could provide custom backbuffer sizes quite easily).

SDL also really needs to have a way to query the physical screen size or actual screen dpi. Creating any kind of reasonable UI for all the different iOS/Android devices is currenlty basically impossible. You can have a device with full HD resolution on a tiny physical screen or an older tablet with much bigger screen and worse resolution. When using only pixels or percentage of screen size for measurement, the UI components will be ridiculously small on the phone or massive on tablets.

All these points have been mentioned before, but somehow I get the impression people think the current state is OK. For portable mobile development it really is not.
High dpi, was Re: IOS 8 progress
Daniel Bünzli
Guest

Le lundi, 8 décembre 2014 à 23:30, ollika a écrit :

Quote:
SDL also really needs to have a way to query the physical screen size or actual screen dpi.

There's a feature request in the bug tracker about that, see https://bugzilla.libsdl.org/show_bug.cgi?id=2473

Best,

Daniel


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
High dpi, was Re: IOS 8 progress
Sik


Joined: 26 Nov 2011
Posts: 905
2014-12-08 19:30 GMT-03:00, ollika:
Quote:
There are at least two good reasons to allow defining a custom backbuffer
size (effectively the "screen size" from SDL apps perspective): games using
a fixed resolution and 3d games that cannot afford to run on the full
(sometimes massive) resolution that some devices have. Using some kind of
scale multiplier or binary flag here is NOT a good solution. Currently if
you are using just OpenGL for rendering. You are basically restricted to
native resolution on android and a couple of fixed options on iOS (You could
implement rendering to texture, but that would just waste time and memory
and add complexity when SDL could provide custom backbuffer sizes quite
easily).

Actually, pretty sure you can get SDL render to an off-screen buffer
and then scale it when using the renderer API (and when not, well what
you do is outside of SDL's reach anyway).
_______________________________________________
SDL mailing list

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