|
|
|
Home » U++ Library support » Draw, Display, Images, Bitmaps, Icons » Native DPI
| Re: Native DPI [message #44748 is a reply to message #44747] |
Mon, 15 June 2015 00:00   |
Tom1
Messages: 1289
Registered: March 2007
|
Senior Contributor |
|
|
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?
I agree, this is far better than the microsoft way of scaling the already rendered bitmaps.
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.
--
As a general note, I think the solution should be engineered having potential future platforms (such as tablets and phones) in mind, so that their scaling requirements do not require redesign of the solution.
Best regards,
Tom
|
|
|
|
| Re: Native DPI [message #44750 is a reply to message #44748] |
Mon, 15 June 2015 14:01 |
 |
mirek
Messages: 14193
Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Mon, 15 June 2015 00:00Hi,
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?
We we still speaking theoretically, but the answers would be:
1. Not yet 100% sure... 
2. You call something like "HiDPIAware();" in constructor.
Quote:
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 would not mix any physical resolution into it (I never considered the "dpi" concept viable for display). For non-aware Ctrl, one "logical" pixel would equal to two "physical" pixels, that is all.
(OK, I know that this might burn us again if "quadruple HiDPI" ever happens...
Quote:
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.
Mirek
|
|
|
|
| Re: Native DPI [message #44754 is a reply to message #44750] |
Tue, 16 June 2015 22:13 |
Tom1
Messages: 1289
Registered: March 2007
|
Senior Contributor |
|
|
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.
Best regards,
Tom
|
|
|
|
| Re: Native DPI [message #44755 is a reply to message #44754] |
Tue, 16 June 2015 23:37 |
|
mirek
Messages: 14193
Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Tue, 16 June 2015 22:13Yes, 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.)
It is "hidpi aware" flag...
Quote:
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?
Now this is a good question (one I am thinking about since the last exchange). Somehow StdFontSize must be different based on HiDPI-awareness...
Quote:
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 am not quite sure what you are speaking about here... Non-HIDPI-aware widgets does not mean all is fixed.
Mirek
|
|
|
|
| Re: Native DPI [message #44757 is a reply to message #44755] |
Wed, 17 June 2015 10:02 |
Tom1
Messages: 1289
Registered: March 2007
|
Senior Contributor |
|
|
Hi,
Sorry, my explanation on "hidpi aware" flag vs. "display zoom percentage" was misleading even to my self after six hours of sleep... Let's try again:
- When "Hidpi aware" flag is set, the coordinates on the Ctrl are equal to physical pixel coordinates. When not set, the Ctrl exposes logical coordinates, which are automatically mapped to physical pixel coordinates (and back) internally in upp according to "display zoom percentage". This will enable compatibility for existing (non-hidpi-aware) Ctrls.
- The "hidpi aware" Ctrls will need additional support from upp to scale their content correctly themselves. This additional support should include a function call to retrieve current display zoom percentage and a function call to retrieve current StdFontSize. Both are needed to get clean results.
In Windows the default font size can be adjusted separately. Please take a look at Control Panel > All Control Panel Items > Display: There you can see "Change the size of all items". The Smaller/Larger -slider changes the Windows reported "DPI". Additionally, on the same page you can see "Change the text size only". A pair of drop lists is used to adjust font size for different text items. It seems TheIDE uses the font size derived from "Menus" font size.
--
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.
Best regards,
Tom
|
|
|
|
| Re: Native DPI [message #44760 is a reply to message #44757] |
Fri, 19 June 2015 08:26 |
|
mirek
Messages: 14193
Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Wed, 17 June 2015 10:02
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.
I guess there is nothing that could prevent hda (hidpi-aware) widgets to use everything.... Anyway, I believe that most of time, scaling to correct standard font height will be enough. We can certainly add something to read display zoom percentage too.
That said, GetStdFont function will become tricky. I have even ugly but perhaps bulletproof plan to have thread local variable that would switch what GetStdFont returns as height... (so that I can setup it before starting Draw method).
[Updated on: Fri, 19 June 2015 08:26] Report message to a moderator |
|
|
|
| Re: Native DPI [message #44768 is a reply to message #44760] |
Mon, 22 June 2015 11:52 |
Tom1
Messages: 1289
Registered: March 2007
|
Senior Contributor |
|
|
Hi,
OK, it sounds like you have it all figured out already. Please let me hear of any progress on the subject.
Thanks,
Tom
|
|
|
|
| Re: Native DPI [message #44786 is a reply to message #44768] |
Fri, 26 June 2015 09:13 |
Tom1
Messages: 1289
Registered: March 2007
|
Senior Contributor |
|
|
Hi,
I just took a look at Windows 10 Pro Insider Preview. It is worth noting that the display scaling range there is 100.. 350% from the default settings and 100.. 500% when accessed through advanced "Custom scaling level" dialog. So it seems Microsoft is already preparing for beyond UHD era already.
Best regards,
Tom
|
|
|
|
| Re: Native DPI [message #44968 is a reply to message #44768] |
Mon, 03 August 2015 20:11 |
|
mirek
Messages: 14193
Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Mon, 22 June 2015 11:52Hi,
OK, it sounds like you have it all figured out already. Please let me hear of any progress on the subject.
Thanks,
Tom
Well, I have now started working hard(er) to this. In the end, I have abandoned my "automatic scaling" idea - it in fact was not that hard to 'fix' CtrlLib and TheIDE for HiDPI, so I guess any application can do that as well. So in the end, we will probably follow Microsoft mode, setting "DPIAware" by application (or its manifest), otherwise use windows scaling.
Please check how TheIDE now looks in HiDPI. Image rescaling is still primitive, I hope to employ some smart algorithm for this soon. However, except the visual quality of images, all other glitches should be now reported, filed in RM and fixed.
As you are perhaps the only one with UHD display, I really hope to hear from you... (I was developing using 200% text size on 1080p display...)
Thanks,
Mirek
|
|
|
|
| Re: Native DPI [message #44972 is a reply to message #44968] |
Wed, 05 August 2015 13:03 |
Tom1
Messages: 1289
Registered: March 2007
|
Senior Contributor |
|
|
Hi,
Thanks for the update on this! Here are my observations starting from the installation of build 8788 on Windows 8.1 Professional x64 using 200 % display scaling:
- The 'fine print' on the installer License agreement dialog is truly fine print. It should be about twice as large for 200 % scaling factor. The same is true for the Installation guide dialog.
- The down pointing triangle-arrow on the droplist button seems very small. (The right pointing arrows on similar controls are the right size.)
- 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.
- The Abbreviations code editor font is too small.
- The font in Custom build steps dialog's 'Commands:' and 'Output file(s):' panels is too small.
- The 'SvnSynchronize SVN repositories' dialog's List's first line with 'Working directory' text is too flat. The 'Working directory' text is clipped at the lower edge.
- The 'Find in files' dialog's entry fields / drop lists have down and right pointing triangular arrows. They are all too small.
That's all I could find at this time.
Thanks and best regards,
Tom
PS. Also the Console font (below the code editor in ide) is very small and so are the icons on the right edge of the console too.
[Updated on: Wed, 05 August 2015 13:07] Report message to a moderator |
|
|
|
|
|
| Re: Native DPI [message #44977 is a reply to message #44976] |
Wed, 05 August 2015 15:50 |
Tom1
Messages: 1289
Registered: March 2007
|
Senior Contributor |
|
|
BTW, the Ctrl + mouse wheel (present in TheIDE code editor and also in many web browsers these days) is an excellent way around wrong font size in the UHD environment. However, I would still prefer having it the right size immediately from the installation -- just like it is with most of the Ctrls already.
UPDATE: Maybe the environment dialog could show the font size in percentage compared to the StdFontSize, which is used for e.g. menus. This way it will scale correctly but still offer full configurability.
Tom
[Updated on: Wed, 05 August 2015 15:53] Report message to a moderator |
|
|
|
| Re: Native DPI [message #44991 is a reply to message #44977] |
Sun, 09 August 2015 13:22 |
|
mirek
Messages: 14193
Registered: November 2005
|
Ultimate Member |
|
|
All listed issues should be now fixed.
W.R.T. ide editor font size, I have decided to use "default font" approach - after install, height is defaulted based on zooming (-> OK), but it does not change when system DPI changes.
Notes about "UHD" support, current model:
- Image now has "resolution" attribute, which can be either Standadard, UHD, None
- When Image is created in code, this defaults to None
- IML images have default "standard"
- IML images, if not NONE, are automatically rescaled if mode does not match
- There are functions DPI that can be used to scale int, size or Image based on UHD mode
- Ctrl::SetHiDPIEnabled (maybe I will rename to SetUHDEnabled...) has to be used to activate Windows HiDPI mode.
- Ctrl::[Horz|Vert]LayoutZoom have now global function synonyms Zx and Zy (simply beacause they get called a lot... (Also, there is Zsz returning Size
Looking forward for more bugs to fix...
|
|
|
|
|
|
|
|
|
|
| Re: Native DPI [message #45020 is a reply to message #45018] |
Wed, 19 August 2015 13:07 |
Tom1
Messages: 1289
Registered: March 2007
|
Senior Contributor |
|
|
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?
Best regards,
Tom
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Mon Jan 13 22:52:44 CET 2025
Total time taken to generate the page: 0.02347 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
