Constraint icons size at Sketcher edit (PR ready)

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
chrisb
Veteran
Posts: 53930
Joined: Tue Mar 17, 2015 9:14 am

Re: Constraint icons size at Sketcher edit (PR ready)

Post by chrisb »

Thicker lines would be helpful, especially if they are clearly different from the y-axis. The current color scheme makes it hard to distinguish a semi constrained construction line from the y axis.
Attachments
SnipScreenshot-3618c4.png
SnipScreenshot-3618c4.png (2.25 KiB) Viewed 1964 times
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Constraint icons size at Sketcher edit (PR ready)

Post by abdullah »

chrisb wrote: Wed Jan 06, 2021 10:01 pm Thicker lines would be helpful, especially if they are clearly different from the y-axis. The current color scheme makes it hard to distinguish a semi constrained construction line from the y axis.
I do not fully understand what is expected from a HDPI monitor.

If the goal is that everything is rendered "equal sized" in a HDPI monitor and a LDPI, then I wonder what is the point of increasing the pixel density. So I give you double pixel density and then I make lines with twice the width of pixels so that they look the same.

The current implementation for line width is as follows:

Code: Select all

    edit->CurvesDrawStyle->lineWidth = std::lround(3 * edit->pixelScalingFactor);
    edit->RootCrossDrawStyle->lineWidth = std::lround(2 * edit->pixelScalingFactor);
    edit->EditCurvesDrawStyle->lineWidth = std::lround(3 * edit->pixelScalingFactor);
    edit->ConstraintDrawStyle->lineWidth = std::lround(1 * edit->pixelScalingFactor);
    edit->InformationDrawStyle->lineWidth = std::lround(1 * edit->pixelScalingFactor);
So, normal curves in the sketcher are 3 pixels width. Axes are 2 pixel. Draw handler curves are 3 pixel. Constraints are 1 pixel width. Information layer is 1 pixel width.

Here the pixelScalingFactor is the product of the new preferences scaling factor and the monitor ppi ratio (ppi_monitor/96, where 96 ppi is the legacy desktop ppi).

So if you set preferences to 1.0, and your monitor has 198 ppi, you get a 2 scaling factor.

What you get is: 6 px for curves, 4 px for axes, 2 px for constraints and 2 px for information layer.

I wonder if in this situation one would like that or for example, would like to have 6 px for curves and 4 px for axes to be able to select them well (assuming it is difficult to select), while still having 1 px for constraints and information layer, as these are not selectable.

In another example, if you have one over 300 ppi retina monitor, would you still want 9 px lines and 6 px for axes? Would you still want to keep the thinnest possible lines, 1 px, for non-selectable items or maybe this is too thin? Wouldn't 3 px non-selectable lines be unwantedly thick?

Maybe it is an irrelevant consideration. I really have no idea.

Another consideration is quantisation. If the scaling factor is 1.4, the 1 px line remains 1 px. If it is 1.6, the 1 px line turns 2 px.

So, in your example you should be looking a 3 px line on top of a 2 px axis.

FWIW, I have a 96 ppi monitor (or so reported). I am going to fake the scaling factor by using 1.0, 1.25, 1.5, 1.75 and 2 viewing scale factor. I get this:
1.0 (Line 2 px, Axes 3 px)
1.0 (Line 2 px, Axes 3 px)
Screenshot_20210107_071912.png (4.29 KiB) Viewed 1944 times
1.25 (Line 3 px, Axes 4 px)
1.25 (Line 3 px, Axes 4 px)
Screenshot_20210107_071947.png (4.79 KiB) Viewed 1944 times
1.5 (Line 3 px, Axes 5 px)
1.5 (Line 3 px, Axes 5 px)
Screenshot_20210107_072100.png (5.38 KiB) Viewed 1944 times
1.75 (Line 4 px, Axes 5 px)
1.75 (Line 4 px, Axes 5 px)
Screenshot_20210107_072206.png (6.13 KiB) Viewed 1944 times
2 (Line 4 px, Axes 6 px)
2 (Line 4 px, Axes 6 px)
Screenshot_20210107_072240.png (6.73 KiB) Viewed 1944 times
On an different topic, we might need to change the element constrained color if it interferes with the Y axis...
chrisb
Veteran
Posts: 53930
Joined: Tue Mar 17, 2015 9:14 am

Re: Constraint icons size at Sketcher edit (PR ready)

Post by chrisb »

I'm sure it will be an improvement. As it seems difficult to show with a screenshot what's going on, I may take some photos as soon as it is available.
Changing the element constrained color to something darker could indeed improve things, but we should probably wait before opening the color can of worms again.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Constraint icons size at Sketcher edit (PR ready)

Post by abdullah »

Ok. I think I got a first useful approximation:

- Two configuration parameters, font and scaling factor.
- Font is in pixels as in legacy.
- Constraint Icons and subindices scale with font size.
- Geometry, constraint lines and information layer lines, scale with the new scaling factor (except for marker size, which is independently controlled from the global display "marker size" preference).

How does it look in my ldpi monitor:
Peek 07-01-2021 08-28.gif
Peek 07-01-2021 08-28.gif (345.95 KiB) Viewed 1923 times
If I see no comments, I plan to merge this in the afternoon. ;)
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Constraint icons size at Sketcher edit (PR ready)

Post by abdullah »

Merged.

Let me know your impressions.
User avatar
vanuan
Posts: 539
Joined: Wed Oct 24, 2018 9:49 pm

Re: Constraint icons size at Sketcher edit (PR ready)

Post by vanuan »

abdullah wrote: Thu Jan 07, 2021 11:19 am Merged.

Let me know your impressions.
Awesome work.

I just want to clarify that Coin3D doesn't support HiDPI yet.
Current implementation just scales the low-resolution picture rendered by Coin:

https://github.com/coin3d/quarter/commi ... eR706-R714

Would appreciate if somebody with experience in Coin could weigh in.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Constraint icons size at Sketcher edit (PR ready)

Post by abdullah »

vanuan wrote: Thu Jan 07, 2021 5:52 pm Awesome work.

I just want to clarify that Coin3D doesn't support HiDPI yet.
Current implementation just scales the low-resolution picture rendered by Coin:

https://github.com/coin3d/quarter/commi ... eR706-R714

Would appreciate if somebody with experience in Coin could weigh in.
Thanks for the compliment. I am sure it could have been done better. I will be happy if users can actually leverage it to make FreeCAD workable (or easier to work) with HDPI monitors.

Coin is one of those things where I struggle the most. Ickby worked in the quarter implementation/integration if I remember correctly. He might be able to weigh in.
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Constraint icons size at Sketcher edit (PR ready)

Post by Kunda1 »

ickby wrote: pinged by pinger macro
@ickby care to weigh in ?
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
User avatar
chennes
Veteran
Posts: 3881
Joined: Fri Dec 23, 2016 3:38 pm
Location: Norman, OK, USA
Contact:

Re: Constraint icons size at Sketcher edit (PR ready)

Post by chennes »

I thought at first I had completely misunderstood this work, but looking at @abdullah's animation above, it seems not: on the machine I'm testing on this morning, the scale factor in preferences is ONLY scaling the line widths, not the constraints. Any idea what's going on there?

Here's the build info:
OS: Windows 10 Version 2004
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.23655 (Git)
Build type: Debug
Branch: master
Hash: 714a716575ba8554cbb90bd06710b2021c4724d1
Python version: 3.8.6+
Qt version: 5.15.1
Coin version: 4.0.1
OCC version: 7.5.0
Locale: English/United States (en_US)

I don't know that an image will tell you anything, but here's what I'm seeing on a HiDPI display with a scale factor of 2.0 (and 8x antialiasing turned on):
Sketcher scale.png
Sketcher scale.png (50.68 KiB) Viewed 1782 times
Chris Hennes
Pioneer Library System
GitHub profile, LinkedIn profile, chrishennes.com
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Constraint icons size at Sketcher edit (PR ready)

Post by abdullah »

chennes wrote: Fri Jan 08, 2021 4:41 pm I thought at first I had completely misunderstood this work, but looking at @abdullah's animation above, it seems not: on the machine I'm testing on this morning, the scale factor in preferences is ONLY scaling the line widths, not the constraints. Any idea what's going on there?
I would say it works as per the commit message:
https://github.com/FreeCAD/FreeCAD/comm ... e232059a26

I think that what you mean is that this behaviour of separately treating geometry and constraints is inconsistent in your view and/or that evolved in time from a different behaviour that was proposed before.

I think it is not inconsistent when FreeCAD is looked at as a whole, but it has indeed evolved over time. The reason is to maintain consistency with other preferences and the rest of FreeCAD. I could certainly have been implemented differently. But I am really interested if it does not allow to have an appropriate visualisation in an HDPI monitor. Please report if that is the case. I explain below the underlaying logic of the decision made.

1. Marker size is a global preference (Display, not sketcher display) expressed in pixels and for all WBs. So Marker size is off any scaling for consistency. We could have defined it, not in pixels, but in a real length unit like points or mm. There is an extra reason, the marker bitmaps are generated for given sizes in pixels, so you have a set of discrete values to select from. In use, it is expected that the user tweaks this parameter to his liking/monitor for all the WBs. If we do extra compensations at sketcher level, the Sketcher would be inconsistent with other WBs (we may be double-compensating).

2. Regarding constraints obeying the font size and not the scaling factor (as in previous versions of this PR), the logic goes like this:
2.1. Users tend to want to customize the size of the font independently from the size of the geometry. It may be a matter of taste, but some users want substantially higher fonts than the system font while others want it similar to the system font. Therefore, the need for a font setting, which already existed in master at Skecher level before this PR (it could have been possible to set a second scaling factor with respect to the system font, I opted to maintain the existing font size preference as I could not see an evident advantage).
2.2. The font size is provided for in pixels in preferences. One could observe changes in size of fonts using the same setting as before. The reason is that this pixel setting was being passed to coin, which uses points, directly without conversion. This PR converts pixels to points before passing them to coin.
2.3. Constraint icons use font subindices. Making constraint subindices font independent from the font setting would lead to inconsistency in the preference of the size font. While it is accepted that this font can be smaller (as subindices are smaller than normal fonts), it would be inconsistent that when increasing the font size, the subindices stay the same size (them not obeying the font size user preference).
2.4. Constraint icons could be made increase independently of the subindex font. However, this would lead to not maintaining the aspect ratio of icon-subindex. It was thought to be more consistent to make the icon size dependent on the font size to keep this aspect ratio.
2.5. The decision to keep font subindices proportional to the font size setting inevitably leads to not following the scale factor.

3. While Geometry scaling should not follow font size of user preferences, scaling may still be needed in HDPI monitors. The PR offers an automatic solution that may be overriden to a certain extend by user preferences. For a fixed scaling factor 1.0, the geometry is still corrected by the dpi provided by QT. However, it is observed that for a monitor 1.4 times the default dpi of 96 dpi, a line which defaults to 1px width will still be 1 pixel width due to rounding (truncation), while for a monitor 1.6 times the default dpi of 96 dpi, it would be 2px. The UI scaling factor is there to allow the user the possibility of configuring this scaling to his or her personal taste.

As I was saying before, I am not sure this is the best implementation. It should be an implementation that makes working with HDPI monitors comfortable. Let me know if this is not the case.
Post Reply