dpi aware v2?

[ollydbg]

In the src target, we have a src\resources\resources.rc, which contains such code:

Code

  #if defined(WX_CPU_AMD64)
    #if defined(cbDPI_AWARE_ON)
        wxMANIFEST_ID RT_MANIFEST "amd64_dpi_aware_on.manifest"
        #warning Manifest: amd64_dpi_aware_on.manifest
    #else
        wxMANIFEST_ID RT_MANIFEST "amd64.manifest"
        #warning Manifest: amd64.manifest
    #endif

When in a win 10 PC, I have first monitor which is DPI125%, and a second monitor has DPI 100%. Now if I start C::B in the first monitor, and drag the window to the second monitor, the main window get blurring, so do we need dpi aware v2?

If I under correctly, the v2 version should have dpi for each monitor, see document here:

High DPI Desktop Application Development on Windows - Win32 apps | Microsoft Learn

Any ideas?

[Miguel Gimenez]

For C::B to react to the DPI change it should handle the wxDPIChangedEvent, new in wx3.1.3 and, AFAIK it is not handled currently. Also, it is only generated on Windows 10 1703+

In the link there is more information about DPI handling and manifests.

EDIT: Dragging the window will not generate this event, we could generate it programatically.

[ollydbg]

For C::B to react to the DPI change it should handle the wxDPIChangedEvent, new in wx3.1.3 and, AFAIK it is not handled currently. Also, it is only generated on Windows 10 1703+

In the link there is more information about DPI handling and manifests.

EDIT: Dragging the window will not generate this event, we could generate it programatically.

Thanks, I believe it is a bit hard to fix such issue.

One issue I see from the cc_manager is that the tip window shown on the screen has the different font size as the editor's font.

Here is the screen shot of a PC running Win11 with DPI setting as 150%. It also happens on other Win10 with DPI setting of 125%.

 

[PB]

For C::B to react to the DPI change it should handle the wxDPIChangedEvent, new in wx3.1.3 and, AFAIK it is not handled currently. Also, it is only generated on Windows 10 1703+

EDIT: Dragging the window will not generate this event, we could generate it programatically.

IME, moving a window between monitors with different DPI does generate wxDPIChangedEvent, as long as the application is marked as PMv2 aware.

[Pecan]

For C::B to react to the DPI change it should handle the wxDPIChangedEvent, new in wx3.1.3 and, AFAIK it is not handled currently. Also, it is only generated on Windows 10 1703+

In the link there is more information about DPI handling and manifests.

EDIT: Dragging the window will not generate this event, we could generate it programatically.

Thanks, I believe it is a bit hard to fix such issue.

One issue I see from the cc_manager is that the tip window shown on the screen has the different font size as the editor's font.

Here is the screen shot of a PC running Win11 with DPI setting as 150%. It also happens on other Win10 with DPI setting of 125%.

My experience is that this problem goes away when the Editor/OtherEditorSettings/Technology is set to DirectWrite.

[ollydbg]

My experience is that this problem goes away when the Editor/OtherEditorSettings/Technology is set to DirectWrite.

Hi, Pecan, thanks. Yes, enable DirectWrite can solve calltip font size issue, but the DirectWrite cause other issue. The main problem is that it will crash if you use C::B from remote desktop. I have report this crash issue long time ago(either in wxWidgets' github or in our C::B forum), it was not fixed yet. Not sure how complex to handle it correctly, the main point is the Direct Draw surface should be cleared once an editor get closed.

My guess is that the font size to window size calculation is wrong here in non-DirectWrite mode for constructing the CC's tip-window.

[ollydbg]

IME, moving a window between monitors with different DPI does generate wxDPIChangedEvent, as long as the application is marked as PMv2 aware.

Hi, PB, thanks. I'm testing with the wxWidgets' sample program named "display". I'm not fully understand the logic, and see something unexpected. I will report here or in the wxWidgets' forum.

EDIT:

I have post a question about how FromDIP works in wxWidgets forum, see here: How does the FromDIP function work under different DPI scaling?

[Pecan]

Is any of this true (I'm always skeptical of ChatGPT), and if so, is it of any use to us?

[ollydbg]

Is any of this true (I'm always skeptical of ChatGPT), and if so, is it of any use to us?

For my experience: Sometimes, ChatGPT can give you a sample wx code. Most of the time, the code can't be built, it has many build errors.

If you follow the discussion in this wx forum thread: How does the FromDIP function work under different DPI scaling?, I think the simple way to do this DPI change is just call the "ResetMode()" of the wxDisplay, so that everything get layout again.

I'm not sure my guess is correct, but when I search for the keyword "ResetMode", I don't see much usage. Maybe, I will ask this in wx-user maillist.

EDIT:

I post a question on wx-user maillist here: What is the correct way to response to the wxEVT_DPI_CHANGED event?