Hi,

From a wider point of view, this sounds like the right way to go. Applications with standard controls scale up beautifully in general without any additional effort, and that is important.

However, from my narrow point of view, I additionally need to be sure that I can still have the low level access to "pixel for pixel" graphics. The important questions are:

1. What mechanisms are used for determining the current (per monitor) DPI (or scaling percentage) and how is this information exposed through upp?
2. How do I create a Ctrl that works at the native "pixel-for-pixel" resolution regardless the current DPI?

As I understand it, this automatic scaling is an attempt to remove the concept of pixel as a measure of distance and replace it with a roughly one quarter of a millimeter unit (more precisely one pixel at 96 dpi).

I bet I will use Painter extensively to render correctly scaled graphics within my controls with graphical content. The Painter rendered content will obviously need to be rendered at 1:1 pixel ratio on screen.

Yes, I know: When we talk about Windows, we should avoid physical units -- meters or inches. And when we ask Windows for display DPI, we in fact ask for display scaling percentage. The result 96 "DPI" represents 100 % GUI scaling.

Instead of having just a hidpi flag, how about having a display zoom percentage instead, i.e. 100% for default DPI level and 125, 150, 200 for greater zoom levels, based on what DPI Windows reports. This would allow better control of GUI scaling whenever it is possible, like it is when text is rendered. (And we could drop the term DPI while it is misleading with its false reference to real inches.)

AND: What exactly should be used as the size reference for GUI scaling anyway? Is it the StdFontSize derived from Windows or is it the above zoom percentage derived from monitor DPI, or some strange combination thereof?

Any which way it is, I would prefer having the framework supporting any scaling levels with fine granularity. While icons may cleanly only be scaled to 1x, 2x, 3x, etc., many other aspects of GUI can benefit from greater granularity.

When I wrote: "Any which way it is, I would prefer having the framework supporting any scaling levels with fine granularity. While icons may cleanly only be scaled to 1x, 2x, 3x, etc., many other aspects of GUI can benefit from greater granularity.", I meant: "Hidpi aware" Ctrls should have access to the current "display zoom percentage" value in order to be able to scale their contents equally cleanly for any display zoom percentage (100/125/150/200%). Scaling to just 1x, 2x, 3x... is not enough.

Hi,

OK, it sounds like you have it all figured out already. Please let me hear of any progress on the subject.

Thanks,

Tom

- The code editor font is very small. I think it should be scaled accordingly regardless of the actual point size in user configurable settings. The same is true for the help content.

Hi,

Thanks! The directory selector works as expected now.

Additionally, up-scaled icons surely look sharper too.

I wonder if it would be possible to use 256x256 icons for all purposes now?

I tried to set icon for my TopWindow (using Icon()), but the downscaling does not work as expected. It feels like there is no antialias filtering present before down sampling. If the downscaling algorithm is under U++ control, could it be changed to use some antialias/low-pass filtering algorithm to give better results?

One slightly unrelated question: Why has the flag parameter FD_ZERO for FormatDoubleFix() changed to FD_ZEROS some time since the last release?