We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 5023 - Request: provide SDL_GetWindowDPIScale() for use without renderer or gl context
Summary: Request: provide SDL_GetWindowDPIScale() for use without renderer or gl context
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 2.0.10
Hardware: x86_64 All
: P2 enhancement
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-11 14:03 UTC by Ellie
Modified: 2020-03-18 00:44 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ellie 2020-03-11 14:03:48 UTC 
I suggest you provide SDL_GetWindowDPI(), which should return the same result as when dividing SDL_GetWindowSize()'s result by SDL_GL_GetDrawableSize().

The reason I am asking for this is because when GL initialization fails, the window still exists. Now in an engine situation (an engine implemented using SDL2 I mean) it might be favorable to let the engine-using application catch GL errors and do whatever, in which case the window will still exist. In particular, I want to provide a NULL output for which the pixel dimensions of the drawing area might still be queried, but I don't know how to implement it robustly in that case.

There's SDL_GetDisplayDPI() of course, but since a window can be half on one display, half on the other, which both displays having different DPI factors, I'm not sure whether that would reliably give me a correct value for whatever SDL2 things the drawable size is.

Therefore, I suggest a SDL_GetWindowDPI() would be nice.

PS: it should probably return a float or double to allow 1.5x and such to be returned

PPS: I assume I could possibly do a workaround via getting the window surface or temporarily initializing a software renderer, but I hope you agree that would be pretty hackish
Comment 1 Ellie 2020-03-18 00:44:13 UTC 
I just read somewhere that SDL_GetDisplayDPI() returns or used to return the physical DPI, not necessarily the virtual one.

Therefore, I change my suggestion to name this new function: SDL_GetWindowDPIScale(), returning 1.0 without HighDPI, and 2.0 or whatever the scale factor is in a HighDPI setting. I really wasn't thinking of the physical DPI when making this API change request, but indeed the actual upscale factor used for rendering.