OMEdit should look the same on high-resolution, high-dpi screens

[Francesco Casella]

The recent trend on laptops is to use high resolution (full HD or even 4K) screens on 13- or 14-inch screens. Modern OSs such as Windows 10 support this feature, allowing to show text, buttons and icons with higher resolution, rather then making them look too small. However, applications need to be fine-tuned to work properly in this context. Apparently, OMEdit still has some issues from this point of view.

I just moved from a laptop with a 13-inch screen at 1366 x 768 to a new one with full-hd resolution 1920 x 1080 on a screen of the same size.

In the first attachment, I report an image obtained with the settings of the text width at 100%. Everything is super-small, but that's how also other applications look like, so I guess it's ok, except for the big '+' node icons in the package browser, that show up after a while and look quite odd. When OMC is just started, small arrow heads are shown, which look much nicer, I have no idea why these big things show up after a while.

Since my eyesight is not good as it used to be, I often work at 150% size, which is the recommended setting. OMEdit looks as shown in the second attachment. There are many elements that have scaled up nicely, such as the menu titles, the font of the library browser, the icon and text in the Welcom|Modelling|Plotting|Debugging tabs, and the font in the log window.

Other instead have remained at the same size as the 100% case: the window title bar and icon, the icons of the button bar below the menu bar, the font of the documentation browser.

Others still have increased their size too much: the lines used to draw the icons and the connection lines in the diagram view look much thicker than at 100% resolution, when the diagrams are scaled to occupy the same real estate on the screen.

I would recommend the following actions:

• make sure the big + icons do not show up at all in the library browser
• set the font size at 200% (so the effect is even stronger) and make sure that
  • all graphical and textual elements in the OMEdit windows double their size when doing so
  • the diagram view looks the same when zoomed up to the same physical size on the screen

This will be particularly important as screens with really high resolution (such as 4K on a 13" screen) become the norm in a few more years. Applications that don't scale nicely will be unusable, or at least look very old-fashioned.

I would recommend this issue to be fixed for 2.0.0, possibly earlier.

[massimo ceraolo]

@casella, what you see now is the result of huge work done under tickets #4196 #4156 and #4956.

Everything can be perfected, obviously. For instance, I myself don't like the huge appearance of some icons (those in the upper part of Variables browser).
However, please consider that the present situation has a rationale behind, that should be taken into account before making additional changes.

The "+" sign issue is an old story as well (see ticket comments 17 and 18 in ticket #4156).

[Francesco Casella]

Replying to ceraolo:

@casella, what you see now is the result of huge work done under tickets #4196 #4156 and #4956.

Aha. That was before I started monitoring all tickets daily... Thanks for pointing them out.

Everything can be perfected, obviously.

Absolutely. In fact, I see a lot of work has already been done, thanks for the pioneering work. I joined the band of hi-res monitor owners late, when I finally had to use eyglasses anyway :)

For instance, I myself don't like the huge appearance of some icons (those in the upper part of Variables browser).

However, please consider that the present situation has a rationale behind, that should be taken into account before making additional changes.

My rationale is very simple:

• all elements in the GUI (no exceptions) should scale up based on the main screen scaling factor - otherwise the app will look different on very high resolution screens
• Modelica diagrams of the same physical size on a screen should look the same, independently of the OS settings - why should it look different?

Do you see any problem with these two principles?

The "+" sign issue is an old story as well (see ticket comments 17 and 18 in ticket #4156).

ticket:4156#comment17 mentions a bug in QT 5.6, that was fixed in 5.6.1 according to the ​QT bug report. I don't know if we have switched to Qt 5.7 with 1.13; if we haven't, we should definitely use the mainteance relase 5.6.1. @adeas31, can you please take care of this?

[massimo ceraolo]

My rationale is very simple:

• all elements in the GUI (no exceptions) should scale up based on the main screen scaling factor - otherwise the app will look different on very high resolution screens
• Modelica diagrams of the same physical size on a screen should look the same, independently of the OS settings - why should it look different?

Do you see any problem with these two principles?

I totally agree.
A lot of programs, even commercial programs (even Dymola) don't respect this principle, but sooner or later they should, and for sure they will. So Since ticket #4156 I started to prompt to go in this direction.

For me the nastiest issues is the old "+" sign issue, which seems to be very easy to solve: indeed @adeas mentioned to me that there are issues connected to the use for software update of MSYS2. I'm still waiting for developers to make the big leap needed to overcome this nasty issue (mentioned also in other tickets, if I remember well)

I've not checked your diagrams, but the sentence "the connection lines in the diagram view look much thicker than at 100% resolution" makes me think.

The connection line thickness was decided in ticket #4196, where a set of rules was set. What I wanted to say with comment 2 is not to try to create a new thickness rule from scratch, but, instead analyse those in ticket #4196 to see whether they require some change; then implement the changes.

This has already happened with ticket #4965 where connecting line thickness rules were enhanced.
So now the rules are defined by the combined choices of 4196 and 4965.

Just to be sure, maybe "much thicker" means 2 pixels instead of two? If so, probably this is because one pixel was too thin, and it is not possible (or not considered possible) to have 1.6 pixels. I presume that OMEdit does not use fractional pen widths.

I don't know what happens with setting pen width with floating-point precision: Qt allows this, but I've never checked what the effect is. Maybe the graphical engine simulates on screen real values of line widths using colour shades at the line sides?
However, personally I'm at ease in a world in which, when switching from one computer to another or one resolution to another, the width of connecting lines changes from 1 to 2 pixels, if 1 pixel is too thin.

[Francesco Casella]

Replying to ceraolo:

My rationale is very simple:

• all elements in the GUI (no exceptions) should scale up based on the main screen scaling factor - otherwise the app will look different on very high resolution screens
• Modelica diagrams of the same physical size on a screen should look the same, independently of the OS settings - why should it look different?

Do you see any problem with these two principles?

I totally agree.

Good! But see further down regarding rule number 2.

For me the nastiest issues is the old "+" sign issue, which seems to be very easy to solve: indeed @adeas mentioned to me that there are issues connected to the use for software update of MSYS2. I'm still waiting for developers to make the big leap needed to overcome this nasty issue (mentioned also in other tickets, if I remember well)

I'll check with Adeel next week at the devmeeting.

The connection line thickness was decided in ticket #4196, where a set of rules was set. What I wanted to say with comment 2 is not to try to create a new thickness rule from scratch, but, instead analyse those in ticket #4196 to see whether they require some change; then implement the changes.

In fact, those rules go against rule 2 of my rationale. The question is: should the thickness of connection lines (and of lines in general) be invariant with the GUI zoom factor, or should they follow it? Currently, if I go from a 25% to a 200% zoom factor in OMEdit, all objects with an extent scale accordingly, but the thickness of the connection line doesn't change (it's always one pixel with 100% and 125% DPI settings). If this is the intended behaviour, then rule 2 cannot hold, because if I double the DPI factor of my screen the whole diagram (including lines!) becomes twice as big, but then when I resize it back to the original size, the line width doesn't change, so it remains wider, which is exactly what I observed in the two attached png's

I'm not sure if the specification is clear in this respect. It probably should, otherwise diagrams that look nice in one tool will look terrible in another one, but I'm not sure it actually is. After all, I think that line thickness should stay the same when you zoom in and out, otherwise it could get too thin (hence, invisible) when you zoom out, and too gross when you zoom in. So, I guess I need to forgo my rule number 2.

That said, we should probably use aliasing also for connection thickness, so at least we don't have a sudden jump from one to two pixels. Aliasing is already used to render arrow heads and icon text, so why not also using it for lines? I am quite sure that QT allows to do that.

[Adeel Asghar]

In the first attachment, I report an image obtained with the settings of the text width at 100%. Everything is super-small, but that's how also other applications look like, so I guess it's ok, except for the big '+' node icons in the package browser, that show up after a while and look quite odd. When OMC is just started, small arrow heads are shown, which look much nicer, I have no idea why these big things show up after a while.

The big + node icons is the old known issue. But unfortunately we can't fix it now. We are using msys2 on Windows and in order to update the Qt version we have to update gcc version as well which results in compilation problems for MSL.

Other instead have remained at the same size as the 100% case: the window title bar and icon, the icons of the button bar below the menu bar, the font of the documentation browser.

The window title bar and icon is managed by OS and I think it will not scale. I guess you experience the same behavior with other applications as well.
Button bar icons should have been scaled but I believe they didn't scale because OMEdit set a fixed value for it. The value is customizable via Tools->Options->General->Toolbar Icon Size. Maybe you should change this to a percentage value instead of fixed value. I will test it a bit.
Font of the documentation browser should also have been scaled. Don't know what is wrong there. I remember I fixed a similar issue with QWebView, the web view we use for documentation, where it uses the fixed value of 96 DPI. Needs a bit more investigation.

Lines don't scale based on the zoom. OMEdit uses the cosmetic pens (Cosmetic pens are used to draw strokes that have a constant width regardless of any transformations applied to the QPainter they are used with. Drawing a shape with a cosmetic pen ensures that its outline will have the same thickness at different scale factors.). So you might see a difference since you have a different thickness because of different DPI but they don't change on different scale factors.

[Francesco Casella]

Replying to adeas31:

Lines don't scale based on the zoom. OMEdit uses the cosmetic pens (Cosmetic pens are used to draw strokes that have a constant width regardless of any transformations applied to the QPainter they are used with. Drawing a shape with a cosmetic pen ensures that its outline will have the same thickness at different scale factors.). So you might see a difference since you have a different thickness because of different DPI but they don't change on different scale factors.

The description of ​QT cosmetic pen for QT 5.12 says that the pen width is always one pixel wide. This is obviously not true if you look at the 150-percent drawing. Is this another QT bug that has been solved in later versions?

I guess after Adrian is finally through with the API thing, we should update MSYS/QT/gcc, we can't stick to an old version without bugfixes indefinitely.

[Adeel Asghar]

No, it says "A line width of zero indicates a cosmetic pen. This means that the pen width is always drawn one pixel wide, independent of the transformation set on the painter." In your case the width is not zero.

[Francesco Casella]

Replying to adeas31:

No, it says "A line width of zero indicates a cosmetic pen. This means that the pen width is always drawn one pixel wide, independent of the transformation set on the painter." In your case the width is not zero.

OK, so what is the width of the cosmetic pen used to draw all the lines in OMEdit diagrams?

[Adeel Asghar]

It depends what thickness you have used. For MSL models its usually 0.25 mm and OMEdit converts it to pixel using,

pixel = (dpi * mm / 1 inch)

In general dpi is 96 (not in your case as though) it depends on the screen resolution, mm is 0.25 and 1 inch is 25.4 mm.

[Francesco Casella]

Replying to adeas31:

It depends what thickness you have used. For MSL models its usually 0.25 mm and OMEdit converts it to pixel using,

pixel = (dpi * mm / 1 inch)

In general dpi is 96 (not in your case as though) it depends on the screen resolution, mm is 0.25 and 1 inch is 25.4 mm.

OK, so that explains why it gets thicker if I switch to 150% font size, which means the dpi increases by 50%, and so does the number of pixels.

In fact, this sounds good, if one is sligthly visually challenged and needs bigger stuff on screen, it is ok if lines also look thicker.

As @ceraolo hinted at in comment:4, maybe we should just use the ​Antialias rendering hint for those lines, so we avoid that the thickness abruptly changes from one to two pixels (a 100% change) when the font size is increased from 100% to 125% (a 25% change) in the OS settings. Currently, at 125%, the two-pixel width looks really gross, I guess some antialiasing would help getting a nicer look.

We could actually make this optional, so if one has a hi-res screen it can be turned on, otherwise you'd typically get one pixel after rounding.

[Adeel Asghar]

We already use QPainter::Antialiasing for lines whose thickness are > 1 pixel. For example the lines in your 150-percent.PNG are all antialiased.

[Francesco Casella]

I also attached an image at 125%. Indeed, at 150% the lines are two full pixel wide, while at 125% they are slightly less. Apparently, for some reason, it's the 100% image which is too thin to actually use any anti-aliasing, so the curve is one straight pixel.

Maybe a more recent version of QT will have better antialiasing also at lower resolution, we'll see.

[Adrian Pop]

I already have a branch of OMDev on my computer that contains updates to QT and also includes clang. I could compile everything with it but we need to test and check more that everything works fine. I will do that after the workshop next week and I will update OMDev.

[Francesco Casella]

See #5307

[Francesco Casella]

Now that OMDev has been updated to the new QT, everything looks much better, also on a high-DPI screen.

[Adam Dershowitz]

I just tried 1.17.0~dev-112-g79631af and the buttons for "Welcome" "Modeling" "Plotting" "Debugging" only highlight at the top half. If I select one, one the top half turns light in color. And, the same for selecting tabs for different opened models.
Not at all a big deal, and has been happening for a long time, but it seemed related and looks a little odd.
Screenshot attached....

[Adeel Asghar]

OMDev update is only for Windows. This issue is on MAC. It won't fix since we use Qt 4 on MAC and it has issues with high resolution screens. By the way the support for MAC is discontinued after OM 1.16

[Adam Dershowitz]

Replying to adeas31:

OMDev update is only for Windows. This issue is on MAC. It won't fix since we use Qt 4 on MAC and it has issues with high resolution screens. By the way the support for MAC is discontinued after OM 1.16

Oh, No! I'm really sorry to hear that. It has been so good to have a cross platform solution, and OM has been a great application. I do realize that it is extra work to keep things going across different platforms. But, it also encourages the discovery of certain kinds of bugs.

I sure hope that this will be reconsidered.