Forums Bug Reports Dialog on 4K screen

I maintain a fairly complex mIRC script which has a settings dialog which has "Options dbu notheme" and which is opened with "Dialog -mdh". A user with a 4k screen has reported that the dialog is "compacted so I cannot see anything".

I am waiting for more details, but I thought I would ask here if anyone knows of any issues in this area?

P.S. Info I have asked for:

• mIRC version
• Windows version
• Display, graphics card, driver versions
• Screen shot(s)
• Output from "//echo -ac Normal DBU Width: $dbuw DBU Height: $dbuh"

Is there anything else I should ask for?

Is your dialog table set to use pixels or dbus? If its pixels then there's no scaling applied. If its dbu, it should use window's scaling.

With that said, this scaling issue has been brought up a few times
Small Buttons
Small UI

The best end-user solution would be to have two tables: one for smaller res, then one for HD/UHD resolutions

As I said, it has "options dbus".

And I have read both the previous posts before posting, but neither seem to fit.

I don't have a 4k screen and so cannot reproduce this issue. But the dialog scales fine on the various screens I display it on.

(That said, I have worked on other software (python, PyQT) which needs special stuff to support 4K screens.)

When you say the dialog is compacted, is it completely shrunk, or is it somewhat normal size with the text being too small?



I'm curious what are the dbuw/dbuh values relative to the pixels width/height. I was under the impression that dbuw/dbuh were supposed to vary so that pixel-size divided by dbu-size would always be somewhere in the same ballpark.

I am trying hard to help the user, but he is not being very helpful in providing screen shots and diagnostic info.

He has posted a screen shot of the output from:

and it is:


By comparison, on my laptop the results are:


So the values for dbuw/dbuh look OK.

Here is what they look like:
4K
[img]https://ibb.co/hhpxPe[/img]
Normal
[img]https://ibb.co/iDsvAK[/img]

It may be impossible to replicate or resolve without direct access to his machine to test on. It may be possible that custom 'large icons' or 'font zoom' settings on some version of windows behaves unexpectedly and outside of the scope of DBU scale, blowing up the font point scale instead.

Just write a custom scaler that doubles everything in your dialog. Add the option: "Jumbo Mode." Or half the point sizes of your font formattings.

It looks kinda like the dialog failed to correctly scale the text the same way it scaled the size of the control itself.

Perhaps there's a failure to scale the text due to an unavailable font size, or due to font substitution. It would be nice to know the font-name and font-size used in dialog text controls, so they could be used in $width, but I posted a question for it a while back, but there was no answer.

https://forums.mirc.com/ubbthreads.php/topics/260772/Font_Name/Size_in_Dialog_text_#Post260772

It seems to me that the first thing to do is to establish whether this is a general issue on 4K screens, either for my script or for dialogs in general (though if the latter I would have thought it would have been reported by others by now - unless it is the use of options notheme that is causing the issue).

So if anyone else with a 4K screen can check whether they get the same issue - or conversely confirm that they don't - then that would also be helpful to point to whether this is a mIRC issue or something specific to this user.


We have yet to establish definitively whether this is specific to this user or a more general issue.


Anything is possible.

If you can give more precise instructions on what Windows settings should be checked that would be helpful.


I will not be writing a custom scaler that doubles everything in my dialog - that is really not the solution here. This is either common on 4K screens in which case it is a mIRC issue, or specific to this user's settings in which case he needs to fix his settings - either way it is not the script writer's responsibility to find a kludge workaround in order to resolve an issue for a single user.

Actually this sounds very similar - and suggests that there may be a bug in mIRC around scaling of dialogs.

It's my opinion that the dialog looks awesome, and mIRC scaled it perfectly. The problem is when the fonts are rendered at such an extreme point size, that they will mutilate certain paint-jobs of various controls. The controls are all there and properly fitted, neatly arranged, but swelling under the pressure of bloated text.

If it were a pixel vs dbu problem, you would have controls overlapping each other on the x/y positions, and everything would be shifted to the bottom-right or so.

Ok - had the following responses from the user to the echo script:

This doesn't look right to me. Shouldn't the first one have a higher dbuw/h?

I assume these are different screens as first is 16:9 wide-screen and second 4:3 old-style.

However user incorrectly said he was using 1024x768 for the second - and screen shot at 2560x1920 shows it is still corrupt at that resolution.

User also reports that dialogs are fine on mirc 6.35 but not on mIRC 7.44, and that removing `option notheme` makes no difference.

P.S. Still waiting for information (and getting very frustrated by user not giving the information I have requested), however this is starting to look like a mIRC bug to me.

It seems unlikely, but could it be an issue with dbuw/h being non-integer?

Thank you for the plaudit. I would like to hope that the quality of my code style is equally good.

User is STILL not providing detail despite me asking multiple times (grrrrr!!!!), but we have narrowed it down to the Windows 10 setting in System/Display/Scaling. If this is 100% then the dialog is fine, but on a 4K display when you need to set it to (say) 150% or 200% or 250% in order to be able to read anything, then the dialogs come out wonky.

My guess is that mIRC is enlarging the text and Windows is enlarging the text too - so we get double enlargement.

I will try setting the Windows scaling on my PC and see whether I can reproduce it.

There can be several reasons for this. Windows sets the default font for all dialogs based on your display and what the application has specified as the required font in its dialog definitions. There are two font names that dialogs normally use, "MS Shell Dlg" or "MS Shell Dlg 2", which map to different fonts depending on your version of Windows and your Windows language settings. Unfortunately, it gets even more complicated after that. See here for a discussion on this.

That said, the only way to track down the cause would be to 1) have a small example script that I can use to reproduce the issue, and 2) use a 4k monitor, which I do not have at this time.

@Khaled, I have reproduced this issue without a 4K monitor. It is to do with the Windows Settings / System / Display / Scaling.

In Windows 10 1709 you get a dropdown with values of 100%, 125%, 150% and 175%, or you can use custom scaling with any value between 100% and 500%. I need to check, but I think you can also set some sort of scaling in old-style Control Panel, and I will need to test to see if this is the same as custom scaling or something different.

Using non-custom scaling and changing the value in the dropdown changes the display immediately, and the dialog scales ok. It is not necessarily absolutely pixel perfect, but it still looks pretty good.

Using custom scaling if forces you to sign-out and sign-in again before the changes take effect, and this is where the dialog scaling goes wrong even when you use custom scaling with the same values as the dropdowns. We also see the echo command results being different.

I have started to test this comprehensively and record the results - which as you can imagine is time consuming when you have to sign-out/in - and when I have tested it all with sign-out/in I want to retest some of it to see if rebooting between changes of scaling makes any difference.

As soon as I have done this I will report back with full results, but this is definitely an issue between Windows and mIRC. At this stage, I am guessing that Windows does not report scaling consistently between non-custom and custom-scaling and mIRC doesn't know how to handle this.

P.S. Obviously, when you have a 4K display you are much more likely to want Windows display scaling, and perhaps more than the 175% you can get from a dropdown.

It's not limited to 4K, it has something to do with dpi scaling. I can experience this issue on 1080p, it's simply much worse on 4K.

This laptop is 13" 1080p with dpi scaling at 125%. If I remote desktop to my other laptop (1366x768 100% dpi) the problem occurs, but only after mIRC is restarted while remote desktop is active - there's a Windows setting to apply scaling based on log-in resolution vs resolution at program start. The weird part is the exact same script looks fine running natively on the 1080p laptop. Though I don't blame mIRC for this really, Windows has terrible scaling support in general. Its own tools don't even scale properly.

https://i.imgur.com/OaHe7XN.png

Worse on 4K because more likely that you will need scaling > 175% which is custom scaling. As per my previous post, scaling using dropdown values of 125%, 150% or 175% seems to be OK.


You need to specify:

a. Windows version i.e. Windows 10 1709
b. Whether it is 125% using the dropdown or custom scaling or old-style control panel.


Aaarrrrrrrrgggggggggghhhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!!! Please let's not complicate this at the moment by introducing issues that occur when you are using remote desktop, which has scaling settings at both ends plus variations on remote desktop software. Perhaps we can fix the native issues first, and then look at remote desktop as a second phase.


This image is not an example of Windows own tools not scaling properly.

Ok - I have completed my testing.

1. We get different results immediately after changing scaling using the dropdown compared to then sign-out/in or rebooting. When you change the dropdown the immediate consequence is similar to changing the screen resolution and the mIRC dialog looks fine - but then when you reboot you get genuine scaling and the dialog breaks.

The change of resolution after changing the dropdown is IMO an anomaly.

2. Screen shots of all of the above suggest that this is a general issue with mIRCs handling of scaling other than 100%.

DETAIL
On my system these are the values I get from:

are:

Here are the screen shots:
100%
[img]https://ibb.co/kexY0K[/img]
125%
[img]https://ibb.co/naTHSz[/img]
150%
[img]https://ibb.co/krJHSz[/img]
175%
[img]https://ibb.co/gG6FEe[/img]

Thanks for testing this out. Unfortunately, I have not been able to reproduce the issue. I set my display size to 1680 x 1050, the largest for my monitor. I changed the Windows 10 display scaling to 100%, 125%, 150%, and 175%, signed out and in again, ran the latest mIRC beta, and ran the custom dialog script. It appeared correctly every time.

@Khaled Darn! I thought we had a reproducible issue.

I am running mIRC 7.52 not the beta. I will try the beta later, but I don't see any changes in the change log that would make a difference.

I suppose it could be variations either in Windows 10 version or graphics chip / drivers.

What version of Windows 10 are you running? Mine is 1709.

What graphics are you using? Mine is Intel HR Graphics 4600 on latest drivers from Feb 2018 v20.19.15.4963.

It could be due to the test dialog script that I am using. If you can provide a simple dialog script that reproduces the issue for you, I will test it here.

Ok - a bit of research into Windows 10 and scaling suggests this is a work in progress by Microsoft, and the user's experience and what they can do about it will vary depending on what version of Windows 10 they are running.

Here are a few articles I have found on this:

• Windows scaling issues for high-DPI devices
• Display Scaling in Windows 10 (RTM)
• Display Scaling changes for the Windows 10 Anniversary Update
• Announcing Windows 10 Insider Preview Build 15002 for PC (Windows 10 1703 or 1709)
• Announcing Windows 10 Insider Preview Build 17063 for PC (Windows 10 1803)

If you want to support high DPI properly, then you probably need to implement High DPI functionality as described here:
Overview of the High DPI technology

If you are on 1703 or later (or possibly 1709 or later) then there is a compatibility setting:
[img]https://ibb.co/f3giZe[/img]
I am not at my laptop right now, but I will test this later to see if it can help.

https://raw.githubusercontent.com/DukeLupus/dlFilter/master/dlFilter.mrc

Not a simple script, but it is the one which we are reporting problems with.

This is definitely a work-around for a genuine issue of display scaling support in mIRC, and of course it only works if you are on Windows 10 1703 or later (so tough if you are still on Windows Vista or 8 or 8.1 or 10 RTM or 10 1607).

Using the compatibility settings in the image above (or the All Users version), select the "Override high DPI scaling behaviour." checkbox and select "System (Enhanced)". (System also works but does it by emulating a lower resolution and fonts are blurred.)

@Khaled - when you are trying to recreate the issue, you might want to check that you haven't got this compatibility option set - or if you are on 1803 that you haven't got Windows 10 1803 automated version of this turned on.

Thanks, unfortunately when trying to track down bugs, I really need a simple script that reproduces the specific issue being reported.

Regarding the custom dialog, I have just noticed that some time ago I added another custom dialog "option" type, in addition to (dbu, pixels, notheme, disable), called "map". This performs the same function as "dbu" but is specific to the dialog being displayed. "dbu" is generic but has to be kept as it is for backwards compatibility.

If you try using "map" as an option type in the dialog definition, does that resolve the issue?

Can't test this until later today but will give it a try.

P.S. Can you explain further what "map" does so I can add it to wikichip?

@khaled - I have just tried it at scaling=100% (i.e. no scaling) and I get a different output with "map" than I do with "dbu":

[img]https://ibb.co/gOic4e[/img]
[img]https://ibb.co/jaeH4e[/img]

The dialog is defined with "size -1 -1 168 227" and ($dbuw==$dbuh==2):

• with "dbu" the dialog is 342x483 and looks perfect
• with "map" the dialog is 258x397 and is squashed.

Given that map is undocumented, I would imagine that very few people will be using it. And so it might be buggy.

OTOH, perhaps the coordinates / sizes work differently with "map", in which case switching to "map" and making a one-time change to all the coordinates and sizes might fix it.

But it really would help to understand what "map" is supposed to do and how it is different from "dbu". Also, I will need to know what version of mIRC "map" was introduced in so that I can know whether I need to increase the minimum version for the script.

P.S. I can see how the actual dialog sizes are calculated for "dbu" - we need to account for the borders and the title bar of the dialog (so 342 = 168*2 + 6 and 483 = 227*2 + 29 - with notheme we get a 1px border and 2px margin all around which makes 6px for width and the title bar is 22px high + 1px gap below).

With "map" the borders and title bar sizes look the same, which means that the dbu-type scaling is different for width and height with = 1.5, height = 1.621145 which makes no sense. OTOH the absolute differences in size are almost the same 84 for width and 86 for height. Not sure if that helps you diagnose this issue...

The "map" option is working correctly. Remember, when you specify one of these options, whether it is "pixels", "dbu", or "map", the dialog needs to be designed around that option.

When the "dbu" option was added long ago, it worked correctly for the majority of people, however the method it used was a generic dialog sizing method. The "map" option is an updated method that uses the now recommended method for mapping dialog sizes across different versions of Windows with different system fonts and DPIs.

Once you design a dialog around one of these options, its size and contents should remap correctly across different Windows versions that use different system fonts and DPIs.

@Khaled - Thanks for such a prompt reply. I don't have any issues with resizing the dialog element positions and sizes to use "map" as a one-off exercise, but I need to know which version it was added in.

(In essence, my script currently requires mIRC 7.44, and I would be loath to change to "map" if it needs a later version than this.)

@Khaled - I have updated my dialog to use the new x y w h values for "map" and tried it at 100% and 150% scaling, and I am pleased to report that it scales pretty well wwhen using "map".

So we now have two alternative solutions:

1. If the dialog uses dbu then you can use mIRC compatibility settings on Windows 10 1703 or later to make the dialog scale properly.

2. Or you can switch from "dbu" to "map" and adjust x y w h.