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

[Armel]

Post by Vadim Zeitlin
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]

Post by Armel

Post by Vadim Zeitlin
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

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,
VZ

[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]

Post by 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 :(

Post by Armel
Is this normal?

<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)
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

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,
VZ

[David Connet]

Post by Vadim Zeitlin
A> >
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

[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.

Regards,
VZ

[Armel]

Post by Vadim Zeitlin
DC> >
DC> > A> >
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.

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

[Armel]

Post by Vadim Zeitlin
A> >
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]

Sent: Wednesday, January 29, 2014 7:48 AM
Subject: Re: Re[2]: Guide to High DPI handling in wxWidgets?

A> >
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

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

[p***@gmail.com]

Post by Vadim Zeitlin
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<http://msdn.microsoft.com/en-us/library/ms633543.aspx> function
in Windows Vista and later versions sets the current process as DPI-aware.
However, the use of the SetProcessDPIAware<http://msdn.microsoft.com/en-us/library/ms633543.aspx> function
is discouraged. For example, if a DLL caches DPI settings during
initialization, invoking SetProcessDPIAware<http://msdn.microsoft.com/en-us/library/ms633543.aspx> 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<http://msdn.microsoft.com/en-us/library/ms633543.aspx>
."

"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 SetProcessDPIAware<http://msdn.microsoft.com/en-us/library/ms633543.aspx>on
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

[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 :-)