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.