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