PureBasic Forums - English

Posted: **Sat Feb 16, 2013 2:27 pm**

Just one feature I wish you guys had added just one more feature.
As today I had to add Window_ScaleDPIx() and Window_ScaleDPIy() to every place a window or gadget had a X or Y or W or H value, and with the program in question it had around 56 GUI elements.
This mean I had to repeat/write Window_ScaleDPIx() 112 times and Window_ScaleDPIy() 112 times in my code.
If PureBasic supported DPIAware and had a DPI Aware option under compiler Options this could be avoided.

With more and more High DPI devices appearing (monitors, pads, tvs) having to make special macros like I do is cumbersome indeed.
Add to this fact that I make sure ALL my applications are DPI Aware and you can imagine all the extra time lost when coding (or rather not coding due to having to replicate this code all the time).
(MacOS X applications are probably DPI Aware by default? Not sure about Linux, but I don't see why not!)

Feature request from 2010 http://www.purebasic.fr/english/viewtop ... =3&t=40515
Code Example (with screenshots) from 2010 http://www.purebasic.fr/english/viewtop ... 12&t=40507

So besides the lack DPI Aware support in 5.10, it is otherwise great, and I'm loving it. Awesome work guys.

Posted: **Sat Feb 16, 2013 3:26 pm**

GDI+ on Windows has a system for switching units used for the function arguments.

By using my gDrawing include for GDI+ on Windows, it works as easy as that:

Code: Select all

gSetUnit(#UnitMillimeter)

After changing the unit, the drawing commands use this unit for their params. Width and height of 10,20 is now 10mm x 20mm,
so output size is the same on devices with different DPI, for example screens and printers.
There are other units available:

Code: Select all

Enumeration ; Unit
    #UnitWorld       ; 0 -- World coordinate (non-physical unit)
    #UnitDisplay     ; 1 -- Variable -- For PageTransform only
    #UnitPixel       ; 2 -- Each unit is one device pixel.
    #UnitPoint       ; 3 -- Each unit is a printer's point, or 1/72 inch.
    #UnitInch        ; 4 -- Each unit is 1 inch.
    #UnitDocument    ; 5 -- Each unit is 1/300 inch.
    #UnitMillimeter  ; 6 -- Each unit is 1 millimeter.
EndEnumeration

Incorporating such a system into PureBasic would be a big task for sure, but it could solve the DPI awareness
problem, if I didn't forget to think about some details?

Use PBSetUnit(#UnitMillimeter) or PBSetUnit(#UnitInch) or PBSetUnit(#UnitPoint) etc., and all commands that
use size and width parameters use the actual unit.
Use it for windows, gadgets, images and drawing, fonts, printing... everything would be independent of the DPI of the output devices.

The huge task would be to add it to PureBasic. Adding a convert function internally for every function param that makes sense:

Code: Select all

Procedure PB_CreateImage(image, width, height)
    width  = CurrentUnitToPixel(width)
    height = CurrentUnitToPixel(height)
    ...
    do usual stuff
EndProcedure

Procedure PB_Box(x,y, width, height)
    x      = CurrentUnitToPixel(x)
    y      = CurrentUnitToPixel(y)
    width  = CurrentUnitToPixel(width)
    height = CurrentUnitToPixel(height)
    ...
    do usual stuff
EndProcedure

- Doable.
- Much work.
- Big benefit for all users on all platforms (in my opinion).

What do you think?

Posted: **Sat Feb 16, 2013 6:16 pm**

I agree it would be nice, but about your current problem:

Rescator wrote: This mean I had to repeat/write Window_ScaleDPIx() 112 times and Window_ScaleDPIy() 112 times in my code.

I know it's not a terrific solution, but if you do that kind of thing often, maybe you could build an include like the one below:

Code: Select all

EnableExplicit


#dpi_aware = 1

; your include start here

CompilerIf #dpi_aware = 1

Procedure.i _OpenWindow (w,x,y,iw,ih,title$,flags,parent)
 ProcedureReturn OpenWindow (w,x*2,y*2,iw*2,ih*2,title$,flags, parent)
EndProcedure

Macro OpenWindow(w,x,y,iw,ih,title,flags=#PB_Window_SystemMenu,parent=0)
 _OpenWindow(w,x,y,iw,ih,title,flags,parent)
EndMacro

CompilerEndIf
; include end 


Procedure Main()
 Protected iEvent
 
 If OpenWindow(0, 50, 50, 640, 480, "Test Window")  
    Repeat 
        iEvent = WaitWindowEvent()             
    Until iEvent = #PB_Event_CloseWindow    
 EndIf
EndProcedure

Main()

In practice you add redefinitions of the PB gui commands you use, you don't need to to them all at once, one at the time, those you find yourself using in a particular project. So it will populate itself almost effortlessly.

You replace the *2 in the example with your dpi aware functions and you can transparently activate/remove the include hopefully without side effects (you have to pay attention to define suitable values for the optional params).

Posted: **Sat Feb 16, 2013 6:24 pm**

I also use your DPI aware code alot, but a trick i use is to make the gadget extra large to start with, so there is no problem when the system runs at a larger DPI (like mine, i use 119DPI in windows for extra large font!)

I use this trick because gadgets in linux usually need to be larger than in windows.

Posted: **Sat Sep 03, 2016 10:42 pm**

Should up that topic. Idea to add adaptive design support to PB UI system looks good now as for me, recently DPI question became really painful thing, there are too many ppl using "125% scaling", etc, and not more enough to make some nice fixed GUI basing on 96 DPI.

( Yet another stupid trend to deal with. How I like to see when people making things complicated -- just because they had nothing to do, after did something which was fine already :3 )

Posted: **Sun Sep 04, 2016 5:21 pm**

A fixed GUI at 96 DPI would have almost unreadable text on a 20-30 inch 5K monitor, and since it's fixed you can't make it larger. If it was DPI aware the user could just adjust the DPI setting in the OS.

But back to PureBasic. We need the implementation such that we avoid using a macro 112 times like I mentioned in the original post, or wrapping all PB GUI functions used.
The best way is to simply use 96 DPI internally and then use the Windows API to translate that to the OS/session DPI.

But even then there are still some minor things to be aware of, a GUI may end up with a pixel just being 1 or 2 pixels big but even 1.4 pixels big.
So all GUI design need to be aware of how things can seem 1 pixel off sometimes at certain DPI settings.
The simplest fix is to simply leave a minimum of 1 pixel space around all elements (And test at various DPI settings, a virtual machine is a nice way to test this with a older OS, with Windows 10 and 8 and 7 you can make testing accounts for this, a 200% DPI account for example, plenty apps break horribly).

Posted: **Sun Sep 04, 2016 10:47 pm**

I really like Danilo's suggestion. We don't need to have so many unit choices, just the one - perhaps PB's own unit?

Posted: **Wed Sep 07, 2016 2:51 pm**

@IdeasVacuum
PB would not need it's own unit, it would simply be "Pixel" but at 96 PPI.
I forget exactly which API it was but you can use a Windows API to transform from virtual pixels (96PPI) to screen pixels (user/display set PPI).

This means that as a GUI designer you'd work with a window that is 1000x500 pixels, but on screen it will be 1250x625 if the user/display/system/os/monitor is set to 125% "DPI".
Internally PB will need to juggle a few more numbers though, but as the developer you won't have to worry about this.
PB would also need some handling code to deal with Windows 8 and later when it comes to multiple monitors with different PPI, as the main monitor could be 125% DPI but the left could be only 107% DPI.

For example there are people out there that like to use a measuring tape and align the custom DPI slider so the lines match up with the real measuring tape and that way get a 1:1 real world pixel density ratio, aka native per monitor DPI.
That way when moving a window from one monitor to another it will remain exactly the same size despite the monitors having different sizes and different PPIs.

Posted: **Fri Aug 11, 2017 2:07 pm**

+1

Thank you PB team for considering this badly needed feature

Posted: **Fri Aug 11, 2017 2:11 pm**

In general, DPI awareness would be great. But for all supported platforms and also for XML dialogues.

+1

Posted: **Fri Aug 11, 2017 7:13 pm**

How could I miss this thread?

+1 from me, too, of course

Posted: **Sun Aug 13, 2017 7:24 pm**

Posted: **Sun Aug 13, 2017 8:00 pm**

Posted: **Fri Sep 15, 2017 12:59 pm**

Posted: **Mon Sep 18, 2017 2:55 pm**

+∞

PureBasic Forums - English

DPI aware

DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware

Re: DPI aware