Constraint icons size at Sketcher edit (PR ready)
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Constraint icons size at Sketcher edit (PR ready)
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 (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.
Re: Constraint icons size at Sketcher edit (PR ready)
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);
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:
On an different topic, we might need to change the element constrained color if it interferes with the Y axis...
Re: Constraint icons size at Sketcher edit (PR ready)
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.
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.
Re: Constraint icons size at Sketcher edit (PR ready)
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: If I see no comments, I plan to merge this in the afternoon.
- 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: If I see no comments, I plan to merge this in the afternoon.
Re: Constraint icons size at Sketcher edit (PR ready)
Merged.
Let me know your impressions.
Let me know your impressions.
Re: Constraint icons size at Sketcher edit (PR ready)
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.
Re: Constraint icons size at Sketcher edit (PR ready)
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.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.
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.
Re: Constraint icons size at Sketcher edit (PR ready)
@ickby care to weigh in ?ickby wrote: pinged by pinger macro
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
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
Re: Constraint icons size at Sketcher edit (PR ready)
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):
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):
Re: Constraint icons size at Sketcher edit (PR ready)
I would say it works as per the commit message: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?
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.