[PB 5.70b2] DPi Scaling not affecting 2D drawing functions ?

[Blue]

I haven't tried all the 2D drawing functions, but those I have tried were not adjusted with the DPi factor

The following, adapted from the example in the Help file, demonstrates this :

Code: Select all

EnableExplicit

#couleur_bleu1   = $C8B594
#couleur_bleu2   = $AA7929
#couleur_orange  = $1071FB
#couleur_vert    = $1FE59C
#couleur_fenetre = $10E4FA

Define byBlue, wName$ = "Compiler "+ #PB_Compiler_Version

; :: --------includes ------------
CompilerIf #PB_Compiler_Version < 570
 IncludeFile "D:\Outils\Basic\PB.includes\DPiScaling.pbi" ; can be provided on request
 UseModule DPi_Scaling            ; pour les macros 
 Debug "using DPiScaling module"
 byBlue = #True 

CompilerElse
  ; these macros do nothing 
  Macro DPi4(a1,a2,a3,a4)
  a1,a2,a3,a4
  EndMacro
  Macro DPi(a1,a2)
  a1,a2
  EndMacro
  
  Macro DPiX(a1)
  a1
  EndMacro
  
  Macro DPiY(a1)
  a1
  EndMacro
CompilerEndIf
;.
;- test flag
;  would be practical if PB 5.70 DPi compiler option could be set/reset programmatically...
#dpiAware = 01
If #dpiAware
   ; remember to manually CHECK the Dpi option box in Compiler options 
  wName$ + " DPi-aware"
  If byBlue : wName$ + " (Blue's method)" : EndIf 

Else
   ; remember to manually UNCHECK the Dpi option box in Compiler options 
  wName$ + " NOT DPi-aware"
EndIf
Debug wName$

;- creating window
Define winX, winY, winW, winH
winW = 320 : winH = 260
winX = 100 + #dpiAware * (winW+20)
winY = 100
If 0 = OpenWindow(0, dpi4(winX, winY, winW, winH), wName$, #PB_Window_SystemMenu)
  End
EndIf
SetWindowColor(0,#couleur_orange)

;- window gadgets 
Define gX, gY, gW, gH
gX = 4 : gY = 4  
gW = winW-(gX*2) : gH = winH-(gY*2)  
CanvasGadget(0, dpi4(gX, gY, gW, gH))
SetGadgetColor(0,#PB_Gadget_BackColor, #couleur_vert)

If StartDrawing(CanvasOutput(0))
  DrawingMode(#PB_2DDrawing_Gradient)

  BackColor(#couleur_bleu1)
  FrontColor(#couleur_bleu2)
  LinearGradient(gX, gY, gX, gH)    
  Box(dpi4(gX, gY, gW-gX*2, gH-gY*2))
  
  BackColor(#couleur_orange)
  FrontColor(#couleur_vert)
  Circle(dpi(gW/2,gH/2-1), DPiX(gH/2-gY*2))
  
  StopDrawing() 
EndIf

ButtonGadget(1, dpi4(20,20,90,25),"Button A") 
ButtonGadget(2, dpi4(20,50,90,25),"Button B") 

Repeat
Until WaitWindowEvent() = #PB_Event_CloseWindow

End

[Fred]

The Canvas and other pixel based gadgets are not DPI aware because you may be want to use different images or routine to draw. You will need to adapt your code using DesktopScaleX/Y() to adapt.

[Blue]

So it's by design that you left that out ?
It makes senses when you specify "The Canvas and other pixel based gadgets..."

I think that you ought to make that explicit in the Help file.
It's important that PB users understand this clearly.
Such small, but crucial details, deserve a page of explanation in the Help file,
maybe regrouped some "DPi Scaling in Windows OS" topic page.

Thank you for clarifyng this, Fred, and for removing it from the Bugs section.

[Fred]

Yes. The Gadget itself will be resized properly (as you can see in the screenshot), but the innersize in pixel will be real pixels, and you will probably want to use higher resolution images to avoid blur. The 2DDrawing lib is not scalable anyway, but if you use the vector lib, it's just a matter of scale and it should be done.

[Olliv]

The best way could resume making a draw within a transparent 3D quad sprite and managing this one with TransformSprite() coordinates.

In the way where many screens should be shown, instead of OpenScreen() in render starting, replace it with OpenGLGadget().

[Blue]

@Fred :
Very interesting points. Thanks.

Make good note of what you’re explaining here and work it into a paragraph or two, to be added to the Help file under the yet-to-be-created “DPi Scaling in Windows OS” topic page.
Also, since, as you point out, the programmer will need to know the current display’s X/Y scale factors, will PureBasic be providing new native functions that return these values ?
Are the DesktopScaleX/Y() functions you mention already provided (or in the works) for that ? (even though they'd be Windows OS only)

Anything else we ought to know to fully (and intelligently) adapt our creations to displays with varying DPi values ?

[infratec]

Are the DesktopScaleX/Y() functions you mention already provided (or in the works) for that ?

In PB 5.70 Beta 2 they are available and working.

[Blue]

Are the DesktopScaleX/Y() functions you mention already provided (or in the works) for that ?

In PB 5.70 Beta 2 they are available and working.

They can't be found in the Help file yet,
but, yes, I see them in the AutoCompletion popup.

I tried them. They both always return 0.
I'm probably using them incorrectly.
Would you have the time to post a short working example ?

Thanks.

[infratec]

You can simply do:

Code: Select all

Debug DesktopScaleX(100)

at different desktop settings.
At 100% it returns 100.
It should return different values for other scalings.

[Blue]

You can simply do:

Code: Select all

Debug DesktopScaleX(100)

at different desktop settings.
At 100% it returns 100.
It should return different values for other scalings.

I see. So, the argument is a percentage value.
I suppose that will get documented eventually in the Help file.

I was using the desktop number (0 on my system) as the argument.
No wonder I kept getting 0 as the return value.
Using 100, I do get 125 (the correct value for my HD display), when the compiler DPi option is checked.

Here's a code snippet to verify (useless if you don't have an HD monitor) :

Code: Select all

; adapted from the help file

NbDesktops = ExamineDesktops()

; verify the option and set the IF condition to 1 or 0 accordingly
; wish it could be done programmatically...
If 01
  Text$ = "checked."
Else
  Text$ = "NOT checked."
EndIf

 
; Let's enumerate all the desktops found
For k=0 To NbDesktops-1
  
  Text$ = "Compiler DPi option : " + text$ +#LF$
  Text$ + "Desktop "+Str(k+1) + " of " + NbDesktops +#LF$
  Text$ + "  Name: "+DesktopName(k) +#LF$
  Text$ + "  Size: "+Str(DesktopWidth(k))+"*"+Str(DesktopHeight(k)) +#LF$
  Text$ + "  Color depth: "+Str(DesktopDepth(k)) +#LF$
  
  If DesktopFrequency(k) = 0
    Text$ + "  Frequency: Default" +#LF$ +#LF$
  Else
    Text$ + "  Frequency: "+Str(DesktopFrequency(k))+" Hz" +#LF$+#LF$
  EndIf
  
  Text$ + "  ScaleX: " + DesktopScaleX(100) +#LF$
  Text$ + "  ScaleY: " + DesktopScaleY(100) +#LF$
  Text$ + "====================="
  Debug text$
  MessageRequester("Information", Text$)
  
Next
End

Results on my machine :
—————————————————————
Compiler DPi option : Not checked.
Desktop 1 of 1
   Name: \\.\DISPLAY1
   Size: 1920*1080
   Color depth: 32
   Frequency: 60 Hz

   ScaleX: 100
   ScaleY: 100
=====================;
Compiler DPi option : checked.
Desktop 1 of 1
   Name: \\.\DISPLAY1
   Size: 1536*864
   Color depth: 32
   Frequency: 60 Hz

   ScaleX: 125
   ScaleY: 125
=====================

Thank you, infratec.

[Fred]

The argument is x, width for DesktopScaleX() or y, height for DesktopScaleY(). If your DPI is 100%, it will returns the same value. If your DPI is 125%, it will return the value*1.25 and so on, so the window stays at the same visual position and dimension.

[Blue]

The argument is x, width for DesktopScaleX() or y, height for DesktopScaleY(). If your DPI is 100%, it will returns the same value. If your DPI is 125%, it will return the value*1.25 and so on, so the window stays at the same visual position and dimension.

OK, Fred, with your clear explanation, I now get it.
I just tried both functions in 5.70 b2, and the results match what I expected from your explanation.

Examples :
    DesktopScaleX(1536) returns 1920
    DesktopScaleY(864)   returns 1080

Perfect functions, but poorly named. They definitely don't return a scale as their current names suggest.
They need names that better describe what they do: they return the scaled value of their argument. Therefore, naming them ScaledDesktopX() and ScaledDesktopY() respectively would be accurate and a lot more descriptive. Or, if it's important to you to keep the Desktop part of the name at the beginning, at least call them DesktopScaledX() and DesktopScaledY() (that lonely letter 'd' at the end of the word 'scale' makes all the difference in the world.

[LCD]

I think that you ought to make that explicit in the Help file.
It's important that PB users understand this clearly.

I don't think so. All programmers understands it clearly without explicit mention in the help file.
If you use pixels to define coordinates, then only pixels will be used as coordinates.

[Fred]

The argument is x, width for DesktopScaleX() or y, height for DesktopScaleY(). If your DPI is 100%, it will returns the same value. If your DPI is 125%, it will return the value*1.25 and so on, so the window stays at the same visual position and dimension.

OK, Fred, with your clear explanation, I now get it.
I just tried both functions in 5.70 b2, and the results match what I expected from your explanation.

Examples :
    DesktopScaleX(1536) returns 1920
    DesktopScaleY(864)   returns 1080

Perfect functions, but poorly named. They definitely don't return a scale as their current names suggest.
They need names that better describe what they do: they return the scaled value of their argument. Therefore, naming them ScaledDesktopX() and ScaledDesktopY() respectively would be accurate and a lot more descriptive. Or, if it's important to you to keep the Desktop part of the name at the beginning, at least call them DesktopScaledX() and DesktopScaledY() (that lonely letter 'd' at the end of the word 'scale' makes all the difference in the world.

I agree, will rename them to DesktopScaledX/Y()

[Blue]

Thank you, Fred,
for the name change and for the time given to this topic.
And don’t forget to integrate, somewhere in the Help file, the very clear explanation you gave in the 4th message above this one.