DPI aware
DPI aware
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.
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.
Re: DPI aware
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:
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:
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:
- Doable.
- Much work.
- Big benefit for all users on all platforms (in my opinion).
What do you think?
By using my gDrawing include for GDI+ on Windows, it works as easy as that:
Code: Select all
gSetUnit(#UnitMillimeter)
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
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
- Much work.
- Big benefit for all users on all platforms (in my opinion).
What do you think?
Re: DPI aware
I agree it would be nice, but about your current problem:
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:
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).
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()
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).
"Have you tried turning it off and on again ?"
A little PureBasic review
A little PureBasic review
-
- PureBasic Expert
- Posts: 2810
- Joined: Fri Apr 25, 2003 4:51 pm
- Location: Portugal, Lisbon
- Contact:
Re: DPI aware
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.
I use this trick because gadgets in linux usually need to be larger than in windows.
Re: DPI aware
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 )
( 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 )
"W̷i̷s̷h̷i̷n̷g o̷n a s̷t̷a̷r"
- Roger Hågensen
- User
- Posts: 47
- Joined: Wed Mar 25, 2015 1:06 pm
- Location: Norway
Re: DPI aware
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).
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).
4 music albums under CC BY license available for free (any use, even commercial) at Skuldwyrm.no
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: DPI aware
I really like Danilo's suggestion. We don't need to have so many unit choices, just the one - perhaps PB's own unit?
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
- Roger Hågensen
- User
- Posts: 47
- Joined: Wed Mar 25, 2015 1:06 pm
- Location: Norway
Re: DPI aware
@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.
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.
4 music albums under CC BY license available for free (any use, even commercial) at Skuldwyrm.no
Re: DPI aware
+1
Thank you PB team for considering this badly needed feature
Thank you PB team for considering this badly needed feature
Re: DPI aware
In general, DPI awareness would be great. But for all supported platforms and also for XML dialogues.
+1
+1
-
- Addict
- Posts: 4519
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany