I've recently switched to 4K monitors at home, and noticed that the LLBLGen runtime doesn't correctly perform DPI scaling. Fonts are tiny on 4K resolution.

I'm using 5.7, but I would be suprised if older versions don't have this issue.

For reference, I attached a screenshot of this post with the application on top: https://i.imgur.com/wyTBus2.png

1) try v5.7.1 which has newer controls which correct some DPI issues 2) after setting scaling, first log off/login into windows 3) if you're using 200% scaling, I can't reproduce it, fonts are scaled properly.

See: https://imgur.com/a/F9MZqjl (this is at 4K, 200% scaling)

I see you show the Home tab. If I open the home tab in 5.7.1 @ 200% scaling on 4K it shows normally, no texts are poorly scaled.

My scaling is set to 150%. I'll give 5.7.1 a shot.

Same problem here: scaling is set to 150% and version is 5.7.2. Looks exactly like the screenshot of g.smeets. Some fonts are so small that you can hardly read it.

Chris1 wrote:

Same problem here: scaling is set to 150% and version is 5.7.2. Looks exactly like the screenshot of g.smeets. Some fonts are so small that you can hardly read it.

You changed the scaling in windows right before starting the designer? Is the designer run stand alone or inside vs? Do you use a specific theme in the designer or the default? The scaling to 150% is the only scaling you use?

(edit) The screenshot attached below is taken with 150% scaling on windows 10 1909, 5.7.2.

Thank you for the quick response.

You changed the scaling in windows right before starting the designer?
No, I'm always working at 150%.

Is the designer run stand alone or inside vs?
Standalone.

Do you use a specific theme in the designer or the default?
I tested multiple themes, but there's no difference.

The scaling to 150% is the only scaling you use?
Yes.

I did some more testing:
- 2 physical machines at work: scaling error (Win 10 2004 + 1909)
- 2 Hyper-V-VMs at work: scaling error (Win 10 2004 + 1903)
- physical machine at home: works! (Win 10 1909)

All machines were tested with 5.7.2 at 150% scaling. It's really strange. I have no clue where this is coming from. All other programs don't have display issues.

Ok, it might be something to do with directx usage. The devexpress controls are setup to use directx for rendering. As your home box works, I recon you have a dedicated GPU in that machine, like an nvidia card, but the machines at work don't.

I'll see if I disable directx if that fixes things (or that I can reproduce it at least with that). It's this setting in the config file:

      <setting name="DirectX" serializeAs="String">
        <value>True</value>
      </setting>

(the llblgenpro.exe.config file)

if you change

      <setting name="DPIAwarenessMode" serializeAs="String">
        <value>PerMonitorV2</value>
      </setting>

from PerMonitorV2 to Systemdoes it help?

Testing it here: disabling directx, changing the dpi awareness settings... nothing makes it reproducible. It works every time.

Removing the c:\users<your username>\AppData\Roaming\LLBLGen Pro\PanelState57.xml file might help (and the other files, if you could move them to a different folder temporarily), as that's the devexpress data for the state of the ui, but I can't find anything in there that makes it go wrong in a hidpi environment. (and removing all doesn't have an effect here too.)

Changing DirectX, DPIAwarenessMode, and deleting all XML files has no effect.

Hmm. then I have no idea what causes the differences between the systems... As long as we can't reproduce it here it's hard to track down a fix for it (if that's possible too). for some reason the dpi awareness of the display isn't used by the gui, but I don't know what...

We also use DevExpress, so I did a litte testing. As a result I found out under which circumstances this can happen. What I did not find out is why the behavior is different across machines.

When the application manifest contains the line

<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>

things get messed up (no clue why). The following tests were made with this line.

In my sample application are two SimpleButton controls. Button 1 inherits the font settings from its parent, button 2 has the following settings:

this.simpleButton2.Appearance.Font = new System.Drawing.Font("Tahoma", 9F);
this.simpleButton2.Appearance.Options.UseFont = true;

On my work machines button 1 is displayed incorrectly and button 2 is displayed correctly.
On my home machine both buttons are displayed correctly.

Interesting, thanks for spending time on this!

Our manifest file contains:

    <asmv3:application>
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>True/PM</dpiAware>
        </asmv3:windowsSettings>
    </asmv3:application>

So it's a little different, but I think this is the right value to specify for per-monitor dpi support, which is also what we specify in the .config file (but as things differ per machine, I have no idea what to believe anymore.... )

What I wondered is: do you use a multimonitor setup on the machines that didn't work and not at home (or vice versa) ?

The thing is... the 'Start' label on the home screen which is all botched up in the home tab in the screenshot is defined as:

this.labelControl2.Appearance.Font = new System.Drawing.Font("Segoe UI Light", 18F, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point, ((byte)(0)));
this.labelControl2.Appearance.Options.UseFont = true;
this.labelControl2.Location = new System.Drawing.Point(24, 12);
this.labelControl2.Name = "labelControl2";
this.labelControl2.Size = new System.Drawing.Size(46, 32);
this.labelControl2.TabIndex = 1;
this.labelControl2.Text = "Start";

So it does specify the font (the code above is from the .designer file btw), the only thing perhaps is that it's inside a devexpress PanelControl. (all the elements are).

A simple dialog, e.g. renaming an entity in our designer, does that dialog look ok? If not we could do some testing and build a variant that uses different approaches. (We use XtraUserControls on most tabs/complicated dialogs, have AutoScaleMode set to 'Font').

I still think it's a matter of either specific system aspects or timings, i.e. that the information to determine scaling comes in too late for devexpress to use as it already has laid out the controls on the form/scaled things accordingly.

Reading this https://docs.devexpress.com/WindowsForms/116666/common-features/high-dpi-support suggests not to use a manifest file for this. We'll do some testing and we'll try to build a variant without manifest file suggested dpi awareness to see if that fixes things.

All tested machines have the same setup: 2x 27" 4k displays.

When using

<dpiAware>True</dpiAware>

in the manifest it works. When using

<dpiAware>True/PM</dpiAware>

it doesn't.

The "rename entity" dialog is also displayed incorrectly.

I did some further testing and created a simple Windows Forms dialog without DevExpress components. The problem is there, too. So it seems not to be DevExpress-related.

Thanks man, I'll try to fix this a.s.a.p. and will give you an updated exe for testing.

When I used the DevExpress recommendation of not specifying any dpiawareness in the manifest file (so no usage of the element at all), things didn't work at all, the UI didn't scale properly. When I used True, without /PM suffix things worked again as they should.

So I build a new exe with the corrected manifest, I've attached it to this post. Could you please test this exe to see if it solves the problems on the machines you have problems ? It's 5.7.2 so it should be a drop-in replacement.

It's working now, thank you. :-)

Chris1 wrote:

It's working now, thank you. :-)

Awesome, thanks so much for testing. We'll be shipping a new installer later today!

This also fixes it for me! Cheers.

Great!

Hotfix for 5.7.2 with the fix is now available on the website.