Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[API design] Remove the different points units from all APIs for HighDPI, and always return pixels #3101

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Labels
invalid This doesn't seem right

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.9
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2018-12-13 16:45:42 +0000, Ellie wrote:

Remove the different points units from all APIs for HighDPI, and always return pixels.

This behavior is:

  • badly documented
  • useless because drawing needs to be in pixels anyway, so an SDL2 application cannot just be unaware of DPI (unless ALL SDL2 Apis would be changed to support this)
  • a huge mess because only some APIs use these points and some don't, requiring lots of extra code
  • ... and because on Linux/Windows it is just regular pixels always, even when enabling high dpi

I know this is an intentional idea by Apple, but IMHO in SDL2 apps it does way more harm than good.

I therefore suggest considering reopening & integrating # 3700 and other patches that get rid of this. If you're worried about backwards compatibility, I think the best solution would be an SDL_Init flag that signals that the application expects the sane new behavior.

On 2018-12-14 17:22:00 +0000, Alex Szpakowski wrote:

(In reply to Jonas Thiem from comment # 0)

  • badly documented

I agree that documentation is lacking, but that's no reason to remove a feature critical to making apps behave in a manner that users of a given operating system expect.

(In reply to Jonas Thiem from comment # 0)

  • useless because drawing needs to be in pixels anyway, so an SDL2
    application cannot just be unaware of DPI (unless ALL SDL2 Apis would be
    changed to support this)

If you make SDL only expose pixels, then it will become DPI-unaware and user experience will be broken.

Render-texture creation, glViewport, and interfaces which deal with pixel shaders are just about the only things that actually need to use pixel units, everything else can (and generally should) use DPI-scaled units.

DPI-scaled units should be used for sizing and positioning (both inside the app window and for the window's global coordinates) in order to keep sizing and spacing consistent regardless of the relative DPI scale factor of the screen. For example if I have an 800x600 game window on a 1440x900@2x DPI scaled display, and I move it to a 1920x1080@1x non-DPI-scaled display, I would think the app is broken if it suddenly appeared as (or thought it was) 1600x1200, since it would take up 4 times the effective screen area as before.

(In reply to Jonas Thiem from comment # 0)

  • a huge mess because only some APIs use these points and some don't,
    requiring lots of extra code

It does need some cleaning up to make platforms more consistent, but (as above) it generally shouldn't require extra code except in a couple places.

(In reply to Jonas Thiem from comment # 0)

  • ... and because on Linux/Windows it is just regular pixels always, even
    when enabling high dpi

The overall user experience with DPI-scaled displays on Windows is a big mess (in general, not with SDL2) in large part because Microsoft did not get it right the first time (or the second time, I forget what iteration we're on now with the latest Windows 10 update). I agree that the overall design needs to be consistent, but Microsoft is not the place to look to for positive inspiration in that regard.

I'm not very familiar with the situation on Linux, but I did briefly look into it with X11 at one point and it seemed like there was no simple solution for proper DPI scaling in X11's APIs at the time. I hope things have changed since then.

On 2018-12-17 03:02:10 +0000, Ellie wrote:

If you make SDL only expose pixels, then it will become DPI-unaware and user experience will be broken.

Sorry, I don't understand that comment:

Again as I explained above, applications that want to do DPI-aware rendering already need to deal with an upscaler for all rendering operations, so it is MUCH MORE CONSISTENT to just do that everywhere - as an application author, I mean.

What SDL right now has is just inconsistent and confusing. How exactly does that make my application more DPI-aware?

For example if I have an 800x600 game window on a 1440x900@2x DPI scaled display, and I move it to a 1920x1080@1x non-DPI-scaled display, I would think the app is broken if it suddenly appeared as (or thought it was) 1600x1200, since it would take up 4 times the effective screen area as before.

But wouldn't need SDL need to send a resize event anyway to scale the viewport to the new DPI? Why can't it abstract away the point units, and send a resize event to the according pixel size of each monitor, and always give me the actual pixel size?

I agree that the overall design needs to be consistent, but Microsoft is not the place to look to for positive inspiration in that regard.

I'm not sure I agree. Windows' fully-dpi-aware app mode (different screen DPI aware, essentially) still gives me pixels in SDL right now, everywhere, consistently. That seems more consistent to me than the HiDPI mode of SDL for macOS.

On 2018-12-17 03:09:08 +0000, Ellie wrote:

Also let me add that I don't mind point units at all PER SE.
But if SDL wants to use them, it should use them for:

  1. all events that map to any screen,
  2. window dimensions and positions and screen sizes,
  3. all functions to access input in general,
  4. possibly the render API as well, comparable to web canvas (which defaults to blurry on highdpi unless the app queries the actual res and sets it up highdpi on its own - and the events will still be low dpi/points coordinates, consistently)

If that's not feasible, then SDL should use pixels everywhere. Pick your poison, I don't really care - but the current units mix just doesn't do anyone any good, IMHO.

On 2019-10-26 18:08:26 +0000, Ellie wrote:

Since all comments I got where not in favor of this and with the events also being supposedly in points (are they? that'd be great, actually) the situation being less messy than I thought, I will retract the suggestion if that's ok with everyone.

As a relevant side note though, maybe a nice idea might be to make all SDL_Renderer coordinates floats and also make them in points like e.g. the HTML5/js Canvas behave, at some point. I realize this would be a huge API breakage so this is just a suggestion for the vague future

@SDLBugzilla SDLBugzilla added bug invalid This doesn't seem right labels Feb 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

1 participant