As you have access to HDPI monitors, could you give me some insight about this issue?
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)
That is what I thought until I saw Elyas' screenshot. I do not have Windows either though.
Re: Constraint icons size at Sketcher edit (PR ready)
I measured your screenshots. With font configuration 35px:
Both your screenshots (old and new) and my screenshot:
1. horizontal constraint symbol width = 26 px
2. Subindex of constraint symbol around 16px (without comma)
With the current master configuration:
1. My font height 33 px
2. Your font height 61 px
Is your monitor dpi anywhere around 170-180 dpi?
Re: Constraint icons size at Sketcher edit (PR ready)
I have been looking into the different screenshots (love the GIMP compass measurement tool), I reached the conclusion that Coin needs dpi correction with logical dpi correction. I have no way of testing it.
With this:
git commit 625502bb4770e8bb0d3f4eb5e2150fa353c8c7fb
Let me know how it goes. If you post a screenshot of a fully constrained square (with 35px configuration), I can look into what you are getting as pixel values and maybe I reach a different conclusion...
something like this:
https://forum.freecadweb.org/viewtopic. ... 18#p467529
Re: Constraint icons size at Sketcher edit (PR ready)
Not quite. What coin needs is a proper "HiDPi" support.
That includes:
- actually rendering full-resolution 3D scene camera image instead of scaled up low resolution image
- fonts specified in points
- text scaling (when you set 150%-400% scaling in Windows, Mac or GNOME display settings)
- ability to specify size in percentage of camera perspective instead of pixels and/or a concept if virtual pixels
How it achieves that - using own notion of logical DPIs when rendering fonts (which at this time can only be specified in pixels) or borrowing functionality from Qt (Quarter integration) - is secondary.
Right now I'd write down requirements for coin HiDPI support and how to test them.
And on top of that - what are FreeCAD requirements in relation to that - navicube, axis arrows, sketcher, 3D text, etc
Re: Constraint icons size at Sketcher edit (PR ready)
Very well. But that was not what I mean with needs dpi correction. A better coin would not need dpi correction and would need several things to be a better coin. A better FreeCAD would probably need to review what we use today for configuration. The current FreeCAD and the current coin, if we want to have a reasonable representation, do need dpi correction...vanuan wrote: ↑Sun Jan 17, 2021 9:22 amNot quite. What coin needs is a proper "HiDPi" support.
That includes:
- actually rendering full-resolution 3D scene camera image instead of scaled up low resolution image
- fonts specified in points
- text scaling (when you set 150%-400% scaling in Windows, Mac or GNOME display settings)
- ability to specify size in percentage of camera perspective instead of pixels and/or a concept if virtual pixels
How it achieves that - using own notion of logical DPIs when rendering fonts (which at this time can only be specified in pixels) or borrowing functionality from Qt (Quarter integration) - is secondary.
Right now I'd write down requirements for coin HiDPI support and how to test them.
And on top of that - what are FreeCAD requirements in relation to that - navicube, axis arrows, sketcher, 3D text, etc
It is perfectly fine to define requirements for coin and make a better coin
Re: Constraint icons size at Sketcher edit (PR ready)
I don't know if this is still helpful to you, but here is a fully constrained 50mm square from one of my displays, zoomed out to actual size as measured with a calipers:
Gui.getMainWindow().physicalDpiX() reports that the DPI of that display is 93. (The true physical DPI is 185). FWIW, this is on Windows 10 running at 150% scaling. The relevant settings in FreeCAD are:
Marker Size: 15px
Font Size: 24px
View scale ratio: 2.00
And this is a fresh build of:
OS: Windows 10 Version 2004
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.23721 (Git)
Build type: Debug
Branch: master
Hash: 4c323a63258b94903290fb23426be240c8663950
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)
Gui.getMainWindow().physicalDpiX() reports that the DPI of that display is 93. (The true physical DPI is 185). FWIW, this is on Windows 10 running at 150% scaling. The relevant settings in FreeCAD are:
Marker Size: 15px
Font Size: 24px
View scale ratio: 2.00
And this is a fresh build of:
OS: Windows 10 Version 2004
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.23721 (Git)
Build type: Debug
Branch: master
Hash: 4c323a63258b94903290fb23426be240c8663950
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)
Re: Constraint icons size at Sketcher edit (PR ready)
Further investigation about SoFont.
The mevislab OpenInventor implementation (fork of SGI) doc says that it's in points:
https://mevislabdownloads.mevis.de/docs ... a9f336cdeb
The commercial ThermoFisher fork says it's in pixels:
https://www.openinventor.com/reference- ... Text2.html
https://coin3d.github.io/Coin/html/clas ... a9f336cdeb
Older screens back in the day had resolution of 72 dpi (72 ppi by Macintosh), so printer points were equal to screen pixels. Thus, WYSIWYG - if you put a paper next to monitor they'd have exactly same size of letters of a given font size.
But then Microsoft came in and redefined point size as having 96 points per inch, thus a complex formula of dividing by 72 and multiplying by 96.
After a while, people wanted to change a screen resolution. Higher resolution has allowed to see more detail in pictures, but at the same time, text suddenly become smaller, because OS still assumed screens have 96 dpi resolution. So, instead of forcing software developers to think about the complexity of vector vs pixel graphics, Microsoft and Apple introduced a notion of changeable DPI (96, 128, 192, 256, 512). It was a hack which didn't last long.
Eventually, OS developers couldn't rely on users and developers to remember magic numbers and there was an introduction of device independent pixels and device pixel ratio (also called text scaling or scale factor). So the term DPI slowly falls out of favor being replaced by device pixel ratio which is a relation between physical dpi and logical dpi.
So, for Coin it meas that we either continue using unsustainable practice of scaling fonts by changing SbViewportRegion PPI, or we should figure out how to decouple the physical size of a text as it visible on a screen from the higher detail of renders, so that circles don't look like we're in the 90s.
The mevislab OpenInventor implementation (fork of SGI) doc says that it's in points:
https://mevislabdownloads.mevis.de/docs ... a9f336cdeb
The value is in points for 2D text and is in the current units for 3D text.
The commercial ThermoFisher fork says it's in pixels:
https://www.openinventor.com/reference- ... Text2.html
Though, in SoFont it says it's points:The typeface and size (default = 10) are specified using an SoFont node. Note that for SoText2 the size is interpreted as a value in pixels, not 3D units.
Coin3d fork specifies pixels in both SoFont and SoText2This field specifies the font size. The value is in printer's points for 2D text (SoText2) and is in the current (object space) units for 3D text (SoText3). Default is 10.
https://coin3d.github.io/Coin/html/clas ... a9f336cdeb
There's also The Inventor mentor book:Size of font. Defaults to 10.0.
For 2D rendered bitmap fonts (like for SoText2), this value is the height of a character in screen pixels. For 3D text, this value is the world space coordinates height of a character in the current units setting (see documentation for SoUnits node).
So, apparently, it was meant to be points as in printer points as in 72 points per inch.size (SoSFFloat)
for SoText2, the point size in printer’s points. For SoText3, the size in object
space units (default = 10.0).
Older screens back in the day had resolution of 72 dpi (72 ppi by Macintosh), so printer points were equal to screen pixels. Thus, WYSIWYG - if you put a paper next to monitor they'd have exactly same size of letters of a given font size.
But then Microsoft came in and redefined point size as having 96 points per inch, thus a complex formula of dividing by 72 and multiplying by 96.
After a while, people wanted to change a screen resolution. Higher resolution has allowed to see more detail in pictures, but at the same time, text suddenly become smaller, because OS still assumed screens have 96 dpi resolution. So, instead of forcing software developers to think about the complexity of vector vs pixel graphics, Microsoft and Apple introduced a notion of changeable DPI (96, 128, 192, 256, 512). It was a hack which didn't last long.
Eventually, OS developers couldn't rely on users and developers to remember magic numbers and there was an introduction of device independent pixels and device pixel ratio (also called text scaling or scale factor). So the term DPI slowly falls out of favor being replaced by device pixel ratio which is a relation between physical dpi and logical dpi.
So, for Coin it meas that we either continue using unsustainable practice of scaling fonts by changing SbViewportRegion PPI, or we should figure out how to decouple the physical size of a text as it visible on a screen from the higher detail of renders, so that circles don't look like we're in the 90s.