![]() |
Add support for "system enhanced scaling" |
Post Reply ![]() |
Author | ||
mnissl ![]() Groupie ![]() Joined: 12 June 2018 Status: Offline Points: 12 |
![]() ![]() ![]() ![]() ![]() 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/) 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%: ![]() |
||
![]() |
||
rdhd ![]() Senior Member ![]() ![]() Joined: 13 August 2007 Location: United States Status: Offline Points: 871 |
![]() ![]() ![]() ![]() ![]() |
|
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.
|
||
![]() |
||
mnissl ![]() Groupie ![]() Joined: 12 June 2018 Status: Offline Points: 12 |
![]() ![]() ![]() ![]() ![]() |
|
[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.
|
||
![]() |
||
rdhd ![]() Senior Member ![]() ![]() Joined: 13 August 2007 Location: United States Status: Offline Points: 871 |
![]() ![]() ![]() ![]() ![]() |
|
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?
|
||
![]() |
||
mnissl ![]() Groupie ![]() Joined: 12 June 2018 Status: Offline Points: 12 |
![]() ![]() ![]() ![]() ![]() |
|
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)); |
||
![]() |
||
rdhd ![]() Senior Member ![]() ![]() Joined: 13 August 2007 Location: United States Status: Offline Points: 871 |
![]() ![]() ![]() ![]() ![]() |
|
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.
|
||
![]() |
||
mnissl ![]() Groupie ![]() Joined: 12 June 2018 Status: Offline Points: 12 |
![]() ![]() ![]() ![]() ![]() |
|
There is no sense in passing it to the other API if you want to find out whether the application is GDI scaled.
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:
These are all issues CodeJock is supposed to solve, not Microsoft. |
||
![]() |
||
rdhd ![]() Senior Member ![]() ![]() Joined: 13 August 2007 Location: United States Status: Offline Points: 871 |
![]() ![]() ![]() ![]() ![]() |
|
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.
|
||
![]() |
Post Reply ![]() |
|
Tweet
|
Forum Jump | Forum Permissions ![]() You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |