Print Page | Close Window

Add support for "system enhanced scaling"

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=24320
Printed Date: 28 May 2024 at 4:08pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com


Topic: Add support for "system enhanced scaling"
Posted By: mnissl
Subject: Add support for "system enhanced scaling"
Date Posted: 23 August 2022 at 8:46am
In 2017, Microsoft introduced "GDI scaling" ( https://blogs.windows.com/windowsdeveloper/2017/05/19/improving-high-dpi-experience-gdi-based-desktop-apps/" rel="nofollow - https://blogs.windows.com/windowsdeveloper/2017/05/19/improving-high-dpi-experience-gdi-based-desktop-apps/ ) for DPI-unaware applications where it is too much work or simply possible to make them DPI aware.

"GDI scaling" is also referred to as "enhanced system scaling" and can be activated in the application manifest or by reaching out to the properties dialog of the application file, see section "Configuring a local app to run with enhanced system scaling" in the blog article provided above.

While Toolkit Pro made progress to be DPI aware, there are lots of glitches when it is used with GDI scaling, especially when used with non-integral scale factors like 250%:





Replies:
Posted By: rdhd
Date Posted: 30 August 2022 at 11:19am
I tried this scaling and the results were pretty sad across the board. Microsoft indicated they knew this and were working on yet another approach via a "virtual DPI" system.

I'm not sure CJ can do much about making GDI scaling better.


Posted By: mnissl
Date Posted: 14 September 2022 at 4:15am
[QUOTE=rdhd]
I'm not sure CJ can do much about making GDI scaling better.
[/QUOTE

Of course they can: while a lot of things work out of the box with GDI scaling, some code needs to be adjusted. The very same procedure as with supporting true DPI awareness.

GDI scaling is crucial for MFC applications: there a lot of controls and applications out there which will never support HDPI. GDI scaling is a way to make most of them look acceptably good without touching the source code.

As Codejock made their controls DPI aware, they should also make them compatible with GDI scaling.


Posted By: rdhd
Date Posted: 16 September 2022 at 9:56am
When you build an MFC app, even with VS 2022, there is no choice for GDP+ scaling in the project setting's manifest property page.

When you set an app to be GDI DPI scaled, GetThreadDpiAwarenessContext returns a value which when passed to GetAwarenessFromDpiAwarenessContext will return DPI_AWARENESS_UNAWARE. That value is the same value you get it you set your awareness to "None" in the MFC project manifest setting.

Essentially, I have not seen any difference when asking the thread for its context between DPI_AWARENESS_CONTEXT_UNAWARE and DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED.

The only thing that is aware, is GDI itself from what I've ever been able to tell.

So, how do you determine programmatically what the awareness is?


Posted By: mnissl
Date Posted: 16 September 2022 at 1:09pm
Originally posted by rdhd rdhd wrote:

When you set an app to be GDI DPI scaled, GetThreadDpiAwarenessContext returns a value which when passed to GetAwarenessFromDpiAwarenessContext will return DPI_AWARENESS_UNAWARE.


Yes, the app is DPI-unaware: the app is not aware that it is being GDI scaled. Functions like GetWindowRect() return logical, not physcial coordinates.

But GetThreadDpiAwarenessContext() is your friend: it will tell you that the context is DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED.

This is how an app can detect that GDI scaling is performed:

const auto context = ::GetThreadDpiAwarenessContext();
ASSERT(::AreDpiAwarenessContextsEqual(DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED, context));



Posted By: rdhd
Date Posted: 19 September 2022 at 3:21pm
I see that value and as I noted, I just pass it on to the other API. Again, what are you seeing you think needs to be improved by CJ?

I have made local improvements for some features like dragging docking panes across multiple monitors that have differing DPI scale factors. But, there is nothing I can do about MFC dialogs. Even Microsoft has closed cases I opened against MFC by essentially saying use a different awareness.

Example - just build a MFC old fashioned app with toolbars and don't use their default (which I think is per monitor). Then float a toolbar and try to drag it to another monitor. I have my main monitor set to my 4k scaled at 200%. I can't drag nor resize the MFC floating frame window that hosts the toolbar and get consistent results.

MS Inking also only works for per monitor aware (we use that subsystem in our app) and again, we were told, don't use a setting that doesn't work for MS code.

As I noted, MS told us they know about all the problems in their Apps. Spyxx, Visual Studio and others. Visual Studio find and replace will often show up as a tiny window until I click it. Other MS windows do the same. We were told "wait for the virtual DPI system" they are working on.

And don't even try using multiple monitors with various scaling and then connect from another box using remote desktop. When I get back to the office and sign in, I often find Outlook mail windows are humongous. I have to drag, resize, drag, resize ... until the mail window finally is not extended out to New Mexico.


Posted By: mnissl
Date Posted: 20 September 2022 at 10:23am
Originally posted by rdhd rdhd wrote:

I see that value and as I noted, I just pass it on to the other API.

There is no sense in passing it to the other API if you want to find out whether the application is GDI scaled.

Originally posted by rdhd rdhd wrote:

Again, what are you seeing you think needs to be improved by CJ?

The upper half of the screenshot in my original post represents the ribbon that is drawn by CodeJock, not Microsoft. And it shows several glitches:

  • The big blue rectangle on the left hand side which actually should be the application menu button (which is supposed to fill that white rectangle underneath the QAT).
  • When you mouse over ribbon buttons, the appear and remain blurred (middle section).
  • The "system menu" (minimize, maximize and close buttons) in the top right remains black after you hovered over it -- it should have a white backgorund again.
These are all issues CodeJock is supposed to solve, not Microsoft.


Posted By: rdhd
Date Posted: 23 September 2022 at 11:53am
Passing it on makes perfect sense to me as I don't care about GDI scaling as we simply don't use it. We use either per monitor aware or system aware. I have that code for debugging purposes only so I can track which of the two scaling modes I have enabled programmatically. And, whether a user has overridden that  mode via the advanced properties UI the OS provides for an executable.

When an issue does arise, I just fix them and post here on the forums regarding the same. So far, I have been able to do so without modifying CJ code directly when it comes to DPI scaling issues except in one case that I know of which was due to a 19.3 change related to CJ's use of their auto-scaling mode, which we don't use.

If you want a CJ fix, open a support case.



Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.04 - http://www.webwizforums.com
Copyright ©2001-2021 Web Wiz Ltd. - https://www.webwiz.net