lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] GetContentScaleFactor() always "1"?


From: Vadim Zeitlin
Subject: Re: [lmi] GetContentScaleFactor() always "1"?
Date: Wed, 14 Sep 2022 19:32:20 +0200

On Wed, 14 Sep 2022 15:33:42 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Picking up where I left off before vacation, I remember that running the
GC> automated GUI test under xvfb works with 96 = DPI, but fails with 192 = DPI.
GC> I thought it would be nice to detect that and print a warning if 96 != DPI.
GC> However, this one-line experimental change (I got the idea from
GC>   https://groups.google.com/g/wx-users/c/GE8snC1zwPc
GC> ):

 That was then, but panta rei...

GC> --8<----8<----8<----8<----8<----8<----8<----8<--
GC> diff --git a/main_wx_test.cpp b/main_wx_test.cpp
GC> index af62ad7d2..512b136fa 100644
GC> --- a/main_wx_test.cpp
GC> +++ b/main_wx_test.cpp
GC> @@ -818,6 +818,8 @@ void SkeletonTest::RunTheTests()
GC>          return;
GC>          }
GC>  
GC> +    std::cout << "scale " << MainWin->GetContentScaleFactor() << std::endl;
GC> +
GC>      // Close any initially opened dialogs (e.g. "About" dialog shown 
unless a
GC>      // special command line option is specified).
GC>      for(;;)
GC> --8<----8<----8<----8<----8<----8<----8<----8<--
GC> 
GC> prints "scale 1" and succeeds with DPI =  96, yet
GC> prints "scale 1" and  fails   with DPI = 192, under xvfb.
GC> Running it directly without xvfb, both DPI values still
GC> print "scale 1".
GC> 
GC> What am I missing?

 GetContentScaleFactor() always returns 1 under MSW and there are good
reasons for it, but I'm not sure if you really want to know them (of
course, I'd be glad to explain if you do), so I'll just say that this makes
writing the code that behaves in the same way with wxMSW and wxGTK and
wxOSX easier because you usually don't care about DPI per se but whether
you should scale coordinates or not and under MSW you never do because
logical pixels are always the same as physical pixels there, in any DPI,
see this[1] diagram that even I find helpful to look at sometimes.

 If you really need the DPI scaling and not the "contents scaling", which
is what this function returns, then, as its documentation[2] advises you,
you should use GetDPIScaleFactor() instead, which will return 2 when DPI is
192 under all platforms, including MSW.

[1]: 
https://docs.wxwidgets.org/3.2.1/overview_high_dpi.html#high_dpi_pixel_conversions
[2]: 
https://docs.wxwidgets.org/3.2.1/classwx_window.html#a89cbf94bc15d4e8cb5b1e7db85225577

GC> Should I be doing what's described here:
GC>   https://groups.google.com/g/wx-users/c/GE8snC1zwPc/m/xUoIlw6iAAAJ
GC> i.e.,
GC>   SetProcessDPIAwareFunc pFunc = 
(SetProcessDPIAwareFunc)GetProcAddress(m_user32Dll, "SetProcessDPIAware");
GC> with all the {Load,Free}Library() rigmarole that entails?

 No, definitely not.

 Please let me know if you'd like to know more (sorry in advance if you'd
rather prefer to know less, I'm afraid I can't take what I've already
written back).

VZ

Attachment: pgpFS8JU2lhIk.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]