High dpi, was Re: IOS 8 progress |
Rainer Deyke
Guest
|
On 01.12.2014 10:01, Alex Szpakowski wrote:
(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:
Consistency is good, but I *really* hope the high-dpi API gets fixed/replaced/ditched before it becomes too entrenched to change.
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.
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
|
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.
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
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.
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
|
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:
Yeah, but pretty much all of them fit either into the "fixed resolution" or the "variable resolution" camps.
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.
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 |
High dpi, was Re: IOS 8 progress |
Alex Szpakowski
Guest
|
On Dec 1, 2014, at 11:25 AM, Rainer Deyke wrote:
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:
|
|||||||||||||
|
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:
_______________________________________________ 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:
|
|||||||||||||||
|
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:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
High dpi, was Re: IOS 8 progress |
Ryan C. Gordon
Guest
|
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.
That's a solvable problem.
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:
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:
No, I understand it all right. I just think it's crap.
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.
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:
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
|
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:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
High dpi, was Re: IOS 8 progress |
Ryan C. Gordon
Guest
|
And we give you a way to get that.
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.
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:
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:
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:
-- 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:
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
|
2014-12-03 13:59 GMT-03:00, Eirik Byrkjeflot Anonsen:
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
|
Bit of a tangent regarding Windows:
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:
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
|
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 :
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
|
2014-12-08 19:30 GMT-03:00, ollika:
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 |
|||||||||||||
|