DPI independent GUI system

[DaniloParticipant]

Do we have functions yet, to get the DPI and screen size + screen resolution
on all available platforms?
I need such functions for Font sizes and scaling GUI controls. I think it’s essential, because
it’s a big difference if you run an application on a 96 DPI monitor, or a 220 DPI monitor,
or a 264 DPI iPad Pro.
We can’t use fixed font & control sizes because of this, so some functions to get
the required system informations are essential, in my opinion.
Same thing applies to Printers, because it’s a big difference if you print with
300, 600, 1200, or 2400 DPI.

Your app/game may need to look different on a small iPhone, bigger iPad Pro,
and 27″ or 32″ computer display.

[AdamStrangeParticipant]

Well it is all based on sdl2 so the best place would be to look there.

My initial finding is:

Monkey

int SDL_GetDisplayDPI(int displayIndex, float* ddpi, float* hdpi, float* vdpi)

1 2 3 4

int SDL_GetDisplayDPI(int    displayIndex,                       float* ddpi,                       float* hdpi,                       float* vdpi)

[codifiesParticipant]

would it be adequate enough for your purposes to scale to a fixed ratio (ie 16:9) ?

you can render to a large “virtual resolution” and downscale it depending on the screen size

I posted some code that also scissor clips the letter box as needed.

[codifiesParticipant]

http://monkey2.monkey-x.com/forums/topic/monkey-2-app-template/#post-6538

you’ll need to add

Monkey

[crayon-5cb9b52d17c59167808256 inline="true" ] canvas.Scissor=New Recti( Xoffset*scaleX,Yoffset*scaleY, (960+Xoffset)*scaleX, (540+Yoffset)*scaleY )

1 2 3

[crayon-5cb9b52d17c59167808256 inline="true" ] canvas.Scissor=New Recti( Xoffset*scaleX,Yoffset*scaleY, (960+Xoffset)*scaleX, (540+Yoffset)*scaleY )

[/crayon]

just before drawing on the canvas

the only caveat might be if a small device has sufficient resources to cope with a large virtual resolution

[DaniloParticipant]

Thanks for the hint, AdamStrange!

@codifies:
Scaling is not an option for a GUI system. You may have seen this on Windows,
if you have a high DPI display and set the Windows scaling to 150%, for example.
If an application is not DPI-aware, the OS is scaling the controls, and the result
is blurry looking controls and fonts.
If an application is aware of DPI, it looks clear and crisp on all displays.

[codifiesParticipant]

Scalimg down has always worked finne for me..?

[impixiParticipant]

I have a feeling the high dpi functionality is buggy at SDL2’s end (or within graphics drivers), at least on the MacOS platform. I run the following code on my 5k Retina iMac and receive incorrect results. It states that the DPIs are approx 108 and the desktop resolution is 2560×1440, all incorrect.

EDIT: Just had a thought. The 27″ 5k iMac has a stated resolution of 5120×2880 at 218 PPI. The values I get from my code are half of those values. Might not be a “bug” after all, just “unexpected behaviour”.

Monkey

[crayon-5cb9b52d1f3ae709885473 inline="true" ]#Import "<sdl2>" #Import "<std>" #Import "<mojo>" Using std.. Using mojo.. Using sdl2.. Class MyWindow Extends Window Method New() Super.New( "HIGH DPI", 1024, 768, WindowFlags.Resizable | WindowFlags.HighDPI) Local ddpi:Float Local hdpi:Float Local vdpi:Float SDL_GetDisplayDPI(0, Varptr(ddpi), Varptr(hdpi), Varptr(vdpi)) Print "ddpi: " + ddpi Print "hdpi: " + hdpi Print "vdpi: " + vdpi End Method OnRender( canvas:Canvas ) Override App.RequestRender() canvas.DrawText("Desktop resolution: " + App.DesktopSize.X + " x " + App.DesktopSize.Y, 10, 10) End End Function Main() New AppInstance New MyWindow App.Run() End

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

[crayon-5cb9b52d1f3ae709885473 inline="true" ]#Import "<sdl2>" #Import "<std>" #Import "<mojo>"   Using std.. Using mojo.. Using sdl2..   Class MyWindow Extends Window   Method New() Super.New( "HIGH DPI", 1024, 768, WindowFlags.Resizable | WindowFlags.HighDPI) Local ddpi:Float Local hdpi:Float Local vdpi:Float SDL_GetDisplayDPI(0, Varptr(ddpi), Varptr(hdpi), Varptr(vdpi)) Print "ddpi: " + ddpi Print "hdpi: " + hdpi Print "vdpi: " + vdpi End   Method OnRender( canvas:Canvas ) Override App.RequestRender() canvas.DrawText("Desktop resolution: " + App.DesktopSize.X + " x " + App.DesktopSize.Y, 10, 10) End End   Function Main() New AppInstance New MyWindow App.Run() End

[/crayon]

On the positive side, the undocumented WindowFlags.HighDPI creation flag works nicely, though I need to load my fonts at a larger size, obviously. Text is very sharp. (Ted2 makes use of that flag too).

My next project is very text heavy, so I also would like bug-free DPI-related functionality, if possible…

[DaniloParticipant]

@impixi: Do you need to double the font sizes?

[DaniloParticipant]

Using the flag WindowFlags.HighDPI, the window size gets doubled automatically
when moving a window from normal screen to a HiDPI screen.
But MX2 does not update the render screen size. With Ted2Go it looks like this:

Attachments:

1. 

   ted2ScreenSnapz002.png
   

[impixiParticipant]

Do you need to double the font sizes?

I’d assume it depends on the amount of DPI. Higher amounts would require higher multiples font size. IIRC, Ted2 fonts are really small by default. I have to use the “zoom” functionality of the “View” menu item – but only on the first run.

Not sure about your problem above. Would have to see the relevant code… You might need an additional RequestRender call somewhere or to manually adjust View rects, etc…

[DaniloParticipant]

The problem in the image above is not my code. It is the Ted2Go editor when opened on
a normal screen, and then moved to a Hi-DPI screen. It’s a bug, or missing feature,
in Ted2(go) or MX2.
You can test it if you switch to a Hi-DPI mode while Ted2(Go) is running.

How to Enable HiDPI Mode in Mac OS X

In my opinion the Ted2 fonts are too big, on a normal screen. Using ‘zoom out’ 2 or 3 times helps.

On macOS you could probably use:

Objective-C

[[NSScreen mainScreen] userSpaceScaleFactor];

1	[[NSScreen mainScreen] userSpaceScaleFactor];

to get the scale factor for the fonts. But this example shows it only for
the main screen. It’s a bit more complicated when you use mixed screens and
move a window from 100 DPI screen to a 200 DPI screen at runtime.
NSWindow has also such a method, and it’s probably better to ask the window
for the scale factor, so if the window gets moved onto another screen, the scale factor
should change/update.

[impixiParticipant]

@danilo. Very interesting, thanks for the info… Don’t you just love all the complexity and “edge cases” associated with software development?

[DaniloParticipant]

Yes, I love those cases… and also hate them sometimes… with the goal of fixing
it in the development environment I currently use.
I am testing the DPI-awareness of MX2 to understand the system and make it better
and more useful. Maybe perfect – as perfect would be nice. Perfection is a nice goal.

[Author]

Posts