Guide to High DPI handling in wxWidgets?

[Armel]

Hi,

(in my head High DPI stands for "screens with DPI of large value such 150 and more as opposed to the standard 75 / 90 DPI screens)

Windows 8.1 is out since some time now (and certification for it requires high dpi awareness), OS X Retina as well, and I see from time to time messages about High DPI in the list.

Is there a guide to "how should I code High DPI handling in a wxWidgets application?" or a "state of the art".

Best regards

Armel

[Vadim Zeitlin]

On Tue, 28 Jan 2014 01:32:05 -0800 (PST) Armel wrote:

A> Is there a guide to "how should I code High DPI handling in a wxWidgets
A> application?" or a "state of the art".

For OS X you should provide all your bitmaps in doubled up resolution. For
MSW we don't do anything like this and I don't really know whether we
should. In any case, DPI awareness should IMO be mostly implemented inside
the library and not in the applications using it. So whatever bugs there
are, they should be fixed in wx.

Did you test your program under Windows 8.1 with high DPI? Do you see any
problems with it? And, if so, which ones?

Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Armel]

Le mardi 28 janvier 2014 13:54:32 UTC+1, Vadim Zeitlin a écrit :

On Tue, 28 Jan 2014 01:32:05 -0800 (PST) Armel wrote:

A> Is there a guide to "how should I code High DPI handling in a wxWidgets
A> application?" or a "state of the art".

 For OS X you should provide all your bitmaps in doubled up resolution. For
MSW we don't do anything like this and I don't really know whether we
should. In any case, DPI awareness should IMO be mostly implemented inside
the library and not in the applications using it. So whatever bugs there
are, they should be fixed in wx.

 Did you test your program under Windows 8.1 with high DPI? Do you see any
problems with it? And, if so, which ones?

currently, I am testing with Virtual Box "scaled" mode, specifying a resolution of double HD (3840x2160) and 150% HD

The on-line version of our soft uses wx2.9.4, nearly all "custom" stuff is not scaled (some image buttons, AUI stuff) as if I'd specified that our app was DPI aware... but it is not yet (the Enable DPI awareness is No in Visual Studio...), I believe there is a "XP DPI awareness", scaling only texts, but why the h... would it select that.

There was a strange thing as well, the default font that our app selects is reported to have a height of 6, when it is clear that it should be 9... but 9 / 150% => 6 maybe there is something like a double compensation somewhere

I need to test with current version of wxWidgets as some problems may already be fixed... it seems MS really screwed this, on Mac it is not perfect but at least usable (i.e. nothing to do and everything is just scaled). Upgrading is not straight forward unfortunately for us (wx is somewhat customized), I'll report about that when I have more info.

Regards

Armel

[Armel]

I just tested the property grid sample built from the near last version of wx r75689 (off-the-shelf project nothing touched), all the icons in the toolbar or the property grid are desperately small :(

Is this normal?

Regards

Armel

 

[Vadim Zeitlin]

On Tue, 28 Jan 2014 07:22:59 -0800 (PST) Armel wrote:

A> currently, I am testing with Virtual Box "scaled" mode, specifying a
A> resolution of double HD (3840x2160) and 150% HD

Sorry, what is "150% HD"? Does this mean 144 DPI or something else?

A> The on-line version of our soft uses wx2.9.4, nearly all "custom" stuff is
A> not scaled (some image buttons, AUI stuff) as if I'd specified that our app
A> was DPI aware... but it is not yet (the Enable DPI awareness is No in
A> Visual Studio...), I believe there is a "XP DPI awareness", scaling only
A> texts, but why the h... would it select that.

We don't do anything special for the custom image buttons (including the
ones in AUI) currently. We probably should...

A> There was a strange thing as well, the default font that our app selects is
A> reported to have a height of 6, when it is clear that it should be 9... but
A> 9 / 150% => 6 maybe there is something like a double compensation somewhere

How is this font created? Or, alternatively, what is the size of
wxNORMAL_FONT?

A> I need to test with current version of wxWidgets as some problems may
A> already be fixed...

Unfortunately I don't think there have been any recent changes affecting
this.

A> it seems MS really screwed this, on Mac it is not perfect but at least
A> usable

It could be we and not MS. We currently call SetProcessDPIAware() but it
looks like we don't do enough to be really DPI aware. Something definitely
needs to be done about all the bitmaps, we need to scale them up...

On Tue, 28 Jan 2014 08:48:51 -0800 (PST) Armel wrote:

A> I just tested the property grid sample built from the near last version of
A> wx r75689 (off-the-shelf project nothing touched), all the icons in the
A> toolbar or the property grid are desperately small :(
A> Is this normal?

I guess it is, as the bitmaps are only available in this small size and we
never scale them up currently.

We need to do the same thing in wxMSW as in wxOSX, except there we have
system support for it and in wxMSW we need to do it ourselves. Still, it
shouldn't be too difficult to find out the scaled (ie taking DPI into
account) size of the image and then either check for the existing of image
of this size (wxOSX uses "@2x" suffix, so we could start by handling this,
even though Microsoft recommends having all of "@1.25x", "@1.5x" and "@2x")
or upscale the bitmap with the original resolution to the required size.

Regards,

[David Connet]

>

>I just tested the property grid sample built from the near last version of wx r75689 (off-the-shelf project nothing touched), all the icons in the toolbar or the property grid are desperately small :(
>Is this normal?
>

I "fixed" this in my application by specifically putting:
      <dpiAware>False</dpiAware>
into my manifest. Now windows auto-scales my images. (Since it's in my manifest, that overrides the dpi-api call that wx makes)

VZ> (wxOSX uses "@2x" suffix, so we could start by handling this,
VZ> even though Microsoft recommends having all of "@1.25x", "@1.5x" and "@2x")
And be ready to scale to something in between (or bigger) :-)
I was just playing with that and set mine to 175% and 300% - interestingly, I couldn't set it to 75% (the UI corrected it to 100 when the combo lost focus)

Dave

[Armel]

Thanks Dave, it will be at least a quick fix until I can invest time on this matter.

Armel

[Vadim Zeitlin]

On Wed, 29 Jan 2014 00:23:16 -0800 (PST) Armel wrote:

A> Le mardi 28 janvier 2014 23:26:18 UTC+1, Dave a écrit :
A> >
A> > I "fixed" this in my application by specifically putting:
A> > <dpiAware>False</dpiAware>
A> > into my manifest. Now windows auto-scales my images. (Since it's in my
A> > manifest, that overrides the dpi-api call that wx makes)
...
A> Thanks Dave, it will be at least a quick fix until I can invest time on
A> this matter.

We probably should simply remove SetProcessDPIAware() call from our code.
If it hurts more than helps, there doesn't seem to be any reason to keep
it... But I'm surprised that removing/disabling it doesn't have any
negative consequences for the non-bitmap-based controls. I'd expect them to
look worse without it, don't they?

Regards,

[David Connet]

On 1/29/2014 4:20 AM, Vadim Zeitlin wrote:
> On Wed, 29 Jan 2014 00:23:16 -0800 (PST) Armel wrote:
>
> A> Le mardi 28 janvier 2014 23:26:18 UTC+1, Dave a écrit :
> A> >
> A> > I "fixed" this in my application by specifically putting:
> A> > <dpiAware>False</dpiAware>
> A> > into my manifest. Now windows auto-scales my images. (Since it's in my
> A> > manifest, that overrides the dpi-api call that wx makes)
> ...
> A> Thanks Dave, it will be at least a quick fix until I can invest time on
> A> this matter.
>
> We probably should simply remove SetProcessDPIAware() call from our code.
> If it hurts more than helps, there doesn't seem to be any reason to keep
> it... But I'm surprised that removing/disabling it doesn't have any
> negative consequences for the non-bitmap-based controls. I'd expect them to
> look worse without it, don't they?

My app is pretty simple. Mainly text, lists, a little html. I just did a
quick cursory look, but everything looked right. The toolbar was just
fuzzy (bitmap stretching). (I did my checking in a Win8.1 VM - Windows
just seemed to do "the right thing")

Dave

[Armel]

Le mercredi 29 janvier 2014 13:20:41 UTC+1, Vadim Zeitlin a écrit :

On Wed, 29 Jan 2014 00:23:16 -0800 (PST) Armel wrote:

A> Le mardi 28 janvier 2014 23:26:18 UTC+1, Dave a écrit :
A> >
A> > I "fixed" this in my application by specifically putting:
A> >       <dpiAware>False</dpiAware>
A> > into my manifest. Now windows auto-scales my images. (Since it's in my
A> > manifest, that overrides the dpi-api call that wx makes)
...
A> Thanks Dave, it will be at least a quick fix until I can invest time on
A> this matter.

 We probably should simply remove SetProcessDPIAware() call from our code.
If it hurts more than helps, there doesn't seem to be any reason to keep
it... But I'm surprised that removing/disabling it doesn't have any
negative consequences for the non-bitmap-based controls. I'd expect them to
look worse without it, don't they?

 Regards,
VZ

It depends what you consider worse. Everything is somewhat blurry BUT everything is _usable_ The current situation is that 32x32 icon looks so small (without talking about 16x16 bitmaps in trees) that you cannot perceive their meaning.

I believe that the problem will really be not obvious at all as much hand-coded artwork (all those working on the "1 pixel thick" thing principle, such as lines, rectangles, and so on) is going to be non adapted in particular in wx-user code.

My impression is that if we use SetProcessDPIAware, there should be an opt-in declaration from the wx-user at wxWindow level telling "my code is DPI aware", else a mix of official supported wxWidgets control that are DPI aware windows, wxCode components potentially somewhat outdated and user code won't be able to live together. The non-DPI aware windows could then use some transform on the DC to adapt their expected DPI (some globally set value in the app) to screen DPI.

Just my 2 cents

Armel

[David Connet]

> From: Armel <armel....@elliecomputing.com>

>To: wx-u...@googlegroups.com
>Sent: Wednesday, January 29, 2014 7:48 AM
>Subject: Re: Re[2]: Guide to High DPI handling in wxWidgets?

The other way to look at it is to document that WX does call it. The user can easily set their "corrected" awareness in the manifest. Once you've set it in the manifest any call to SetProcessDPIAware (or the new win8.1 SetProcessDPIAwareness) will fail.  But if wx isn't rescaling images, then I'd say we're not really aware :-)

Dave

[paulc...@gmail.com]

Vadim:

> We probably should simply remove SetProcessDPIAware() call from our code. 
> If it hurts more than helps, there doesn't seem to be any reason to keep it...

There is a useful document that describes things to keep in mind while developing DPI-aware apps [1]. From the document:

"The SetProcessDPIAware function in Windows Vista and later versions sets the current process as DPI-aware. However, the use of the SetProcessDPIAware function is discouraged. For example, if a DLL caches DPI settings during initialization, invoking SetProcessDPIAware in your application might generate a possible race condition. For this reason, we recommend that an application enable DPI awareness by using the application's assembly manifest rather than by calling SetProcessDPIAware."

"By adding the <dpiAware> element to your application's assembly manifest, you mark your application as being DPI-aware. The user32.dll module, which provides Windows user interface functionality, checks the application's DPI awareness setting. If an application is determined to be DPI-aware, the user32.dll module calls SetProcessDPIAwareon behalf of the application."

Another reason for using <dpiAware> is that it allows to specify "per monitor" support in win8.1 as true/pm. I don't see this option with using SetProcessDPIAware.

Paul.

[1] http://msdn.microsoft.com/en-us/library/dd464660%28v=vs.85%29.aspx

[Vadim Zeitlin]

On Wed, 29 Jan 2014 06:35:16 -0800 David Connet wrote:

DC> On 1/29/2014 4:20 AM, Vadim Zeitlin wrote:
DC> > On Wed, 29 Jan 2014 00:23:16 -0800 (PST) Armel wrote:
DC> >
DC> > A> Le mardi 28 janvier 2014 23:26:18 UTC+1, Dave a écrit :
DC> > A> >
DC> > A> > I "fixed" this in my application by specifically putting:
DC> > A> > <dpiAware>False</dpiAware>
DC> > A> > into my manifest. Now windows auto-scales my images. (Since it's in my
DC> > A> > manifest, that overrides the dpi-api call that wx makes)
DC> > ...
DC> > A> Thanks Dave, it will be at least a quick fix until I can invest time on
DC> > A> this matter.
DC> >
DC> > We probably should simply remove SetProcessDPIAware() call from our code.
DC> > If it hurts more than helps, there doesn't seem to be any reason to keep
DC> > it... But I'm surprised that removing/disabling it doesn't have any
DC> > negative consequences for the non-bitmap-based controls. I'd expect them to
DC> > look worse without it, don't they?
DC>
DC> My app is pretty simple. Mainly text, lists, a little html. I just did a
DC> quick cursory look, but everything looked right. The toolbar was just
DC> fuzzy (bitmap stretching).

OK, I've removed SetProcessDPIAware() call from wxMSW for now. It would
still be nice to restore it when we're really 100% DPI aware. But it seems
like it's better to avoid using it until then.

[David Connet]

>Another reason for using <dpiAware> is that it allows to specify "per monitor" support in win8.1 as true/pm. I don't see this option with using SetProcessDPIAware.

>

Because the 8.1 api is SetProcessDPIAwareness :-)

[Armel]

at least it is possible to test that using VirtualBox "scaled" mode on a normal screen (it requires a few calls to the VM via command line to extend the largest acceptable screen size to more than your largest resolution), it requires no specific hardware.

(this Stack Overflow question contains a few hint and the response about VBoxManage is helpful http://stackoverflow.com/questions/1126816/windows-how-to-test-ui-under-high-dpi)

Regards

Armel

 

[David Osipyan]

It is not clear how to determine current DPI using wxWidgets.
Do you know how it is can be done?

[Vadim Zeitlin]

On Thu, 25 Aug 2016 17:08:51 -0700 (PDT) David Osipyan wrote:

DO> It is not clear how to determine current DPI using wxWidgets.
DO> Do you know how it is can be done?

In the latest version, use wxWindow::GetContentScaleFactor().

Regards,

[David Osipyan]

Thanks!

David Osipyan

C++ Software Engineer
Los Angeles, CA
+1 818 245 0343
LinkedIn

[David Osipyan]

Thanks!

[David Osipyan]

it is the same as wxGetDisplayPPI().y in previos versions.
Display scale factor is also needed to make application DPI aware.

[Vadim Zeitlin]

[please don't top post to the mailing list, this makes quoting your
messages awkward]

On Wed, 28 Sep 2016 11:34:14 -0700 (PDT) David Osipyan wrote:

DO> it is the same as wxGetDisplayPPI().y in previos versions.
DO> Display scale factor is also needed to make application DPI aware.
...
DO> >> In the latest version, use wxWindow::GetContentScaleFactor().

Not really sure what do you mean by the "display scale factor".
GetContentScaleFactor() does return what I would call the scale factor, if
your application manifest indicates high DPI support you shouldn't need to
do anything else.

What exactly is the problem with GetContentScaleFactor()?

[Dan Gudmundsson]

Is there anyway to set high DPI support with a function instead of via the manifest?

When I build erlang binding of wxWidgets I don't know if the user application code support high DPI or not,

and I guess the other language bindings have the same issue.

[Eran Ifrah]

For Windows / MinGW, I use this code:

// The function: SetProcessDPIAware seems to be missing

#ifdef __WXMSW__

typedef BOOL WINAPI (*SetProcessDPIAwareFunc)();

#endif

and then somewhere in App::OnInit() I add this:

#ifdef __WXMSW__

    

    m_user32Dll = LoadLibrary(L"User32.dll");

    if(m_user32Dll) {

        SetProcessDPIAwareFunc pFunc = (SetProcessDPIAwareFunc)GetProcAddress(m_user32Dll, "SetProcessDPIAware");

        if(pFunc) {

            pFunc();

        }

        FreeLibrary(m_user32Dll);

        m_user32Dll = NULL;

    }

    

    

    // as described in http://jrfonseca.dyndns.org/projects/gnu-win32/software/drmingw/

    // load the exception handler dll so we will get Dr MinGW at runtime

    m_handler = LoadLibrary(wxT("exchndl.dll"));

    

// Enable this process debugging priviliges

// EnableDebugPriv();

#endif

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to wx-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wx-users

--

Eran Ifrah,
Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org

CodeLite IDE Blog: http://codeliteide.blogspot.com/

[Dan Gudmundsson]

Nice I would really like that to be added to wxWidgets in wxSystemSettings or

something.

/Dan

To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users

--

Eran Ifrah,
Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org

CodeLite IDE Blog: http://codeliteide.blogspot.com/

--

Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 

To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users

[David Connet]

On 9/29/2016 1:24 AM, Dan Gudmundsson wrote:
> Is there anyway to set high DPI support with a function instead of via
> the manifest?

As others have mentioned, yes. Microsoft does recommend using the manifest.

> When I build erlang binding of wxWidgets I don't know if the user
> application code support high DPI or not,
> and I guess the other language bindings have the same issue.

In this case, since someone on top of you is writing code, then you
_really_ shouldn't do _anything_. It's up the that user code to declare
its intentions. (my opinion!)

The API can only be called once. So if you call it and say yes and the
user calls it (later) and says no. Well, they're going to look bad.
Setting it via the manifest does allow a user app to get around what a
library may do under them - the manifest takes precedence.

Dave

[David Connet]

> On Thu, Sep 29, 2016 at 10:27 AM Eran Ifrah <eran....@gmail.com
> <mailto:eran....@gmail.com>> wrote:
>
> For Windows / MinGW, I use this code:
>
> // The function: SetProcessDPIAware seems to be missing
> #ifdef __WXMSW__
> typedef BOOL WINAPI (*SetProcessDPIAwareFunc)();
> #endif

I suspect your WINVER targeting is what is causing this. This is only
available in Vista+

Dave

[Dan Gudmundsson]

Yes exactly what I'm trying to say, though my users don't write the manifest, the manifest comes with the executable and that is erlang (the language/interpreter) which we supply.

Which is why I want a functional interface so that the user can tell if they want to use it or not.

The manifest works for compiled languages like C and C++ but for interpreted languages like lua erlang java? python? a functional interface is needed.

Dan

Dave

[David Osipyan]

I need to set the toolbar images sizes depending on display resolution.
GetContentScaleFactor(0 returns the same value (96x96) for any display resolution.
In my Windows 10 there is a DPI Scaling Level in display settings,
which is also affects to toolbar size.

[Eric Jensen]

Hello David,

Thursday, September 29, 2016, 5:25:18 PM, you wrote:

DO> I need to set the toolbar images sizes depending on display resolution.
DO> GetContentScaleFactor(0 returns the same value (96x96) for any display resolution.
DO> In my Windows 10 there is a DPI Scaling Level in display settings,
DO> which is also affects to toolbar size.

The display resolution has nothing to do with it. The DPI scaling is
relevant. If e.g. you set it to 150% GetContentScaleFactor should
return 1.5.

Eric

[Eric Jensen]

Hello Eran,

Thursday, September 29, 2016, 10:26:55 AM, you wrote:

EI> For Windows / MinGW, I use this code:


EI> // The function: SetProcessDPIAware seems to be missing
EI> #ifdef __WXMSW__
EI> typedef BOOL WINAPI (*SetProcessDPIAwareFunc)();
EI> #endif


EI> and then somewhere in App::OnInit() I add this:


EI> #ifdef __WXMSW__
EI>     
EI>     m_user32Dll = LoadLibrary(L"User32.dll");
EI>     if(m_user32Dll) {
EI>         SetProcessDPIAwareFunc pFunc =
EI> (SetProcessDPIAwareFunc)GetProcAddress(m_user32Dll, "SetProcessDPIAware");
EI>         if(pFunc) {
EI>             pFunc();
EI>         }
EI>         FreeLibrary(m_user32Dll);
EI>         m_user32Dll = NULL;
EI>     }
EI>     
EI>     
EI>     // as described in
EI> http://jrfonseca.dyndns.org/projects/gnu-win32/software/drmingw/
EI>     // load the exception handler dll so we will get Dr MinGW at runtime
EI>     m_handler = LoadLibrary(wxT("exchndl.dll"));
EI>     
EI> // Enable this process debugging priviliges
EI> // EnableDebugPriv();
EI> #endif

I think there is one potential pitfall with this method. This will be
executed when wxWidgets is already initialized. If wxWidgets itself
would use the DPI scaling internally, it would be out of sync with
your application.

You should wrap this in a class and create a global instance of it in
your program. Then it should be called before wxWidgets gets initialized.

Eric

[David Osipyan]

EJ >The display resolution has nothing to do with it. The DPI scaling is
EJ > relevant. If e.g. you set it to 150% GetContentScaleFactor should
EJ > return 1.5.

If DPI scaling  is 100%, GetContentScaleFactor returns 1 for all display resolutions.
So I can't use it to adjust toolbar images size.

[David Connet]

DO> EJ >The display resolution has nothing to do with it. The DPI scaling is

DO> EJ > relevant. If e.g. you set it to 150% GetContentScaleFactor should

DO> EJ > return 1.5.

DO
DO> If DPI scaling is 100%, GetContentScaleFactor returns 1 for all display resolutions.

DO> So I can't use it to adjust toolbar images size.


Um - that doesn't make sense... The only time you should be adjusting image sizes is because DPI scaling is not 100%.

As noted, is has nothing to do with the actual display resolution. If your resolution is 800x600 or 8000x6000 and DPI is 100% in both cases, your code shouldn't do anything different. ***DO NOT*** (I can't scream this loud enough!) adjust your app to screen resolution. I have to use an app like that, and it is the most incredibly awful infuriating (etcetc) experience. To say nothing of the fact that once the screen resolution exceeds a certain point, the app is unusable. And non-4x3 ratios really messes with its sense of reality.

Dave

[David Osipyan]

DO> EJ >The display resolution has nothing to do with it. The DPI scaling is 

DO> EJ > relevant. If e.g. you set it to 150% GetContentScaleFactor should 

DO> EJ > return 1.5. 

DO 
DO> If DPI scaling is 100%, GetContentScaleFactor returns 1 for all display resolutions. 

DO> So I can't use it to adjust toolbar images size. 

Dave > Um - that doesn't make sense... The only time you should be adjusting image sizes is because DPI scaling is not 100%. 
Dave > As noted, is has nothing to do with the actual display resolution. If your resolution is 800x600 or 8000x6000 and DPI is 100% in both cases, your code shouldn't do anything different. ***DO NOT*** (I can't scream this loud enough!) adjust your app to screen resolution. I have to use an app like that, and it is the most 

Dave > incredibly awful infuriating (etcetc) experience. To say nothing of the fact that once the screen resolution exceeds a certain point, the app is unusable. And non-4x3 ratios really messes with its sense of reality. 

Now I understood. Thank you so much!. 
 

[David Osipyan]

 VZ: In the latest version, use wxWindow::GetContentScaleFactor(). 
 

If scaling is increased I set larger image for toolbar button
wxWidgets scales the new image, so instead of 150% the toolbar

button scale is 225%. Is it possible to avoid this double scaling?