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!
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 ...
As you have access to HDPI monitors, could you give me some insight about this issue?
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: Fri Jan 15, 2021 3:42 pm
chennes wrote: Fri Jan 08, 2021 4:41 pm ...
As you have access to HDPI monitors, could you give me some insight about this issue?
There's nothing special about HiDPI monitor. You can uses this setting to emulate the HiDPI monitor on a regular DPI screen:

Image
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: Fri Jan 15, 2021 4:29 pm
abdullah wrote: Fri Jan 15, 2021 3:42 pm
chennes wrote: Fri Jan 08, 2021 4:41 pm ...
As you have access to HDPI monitors, could you give me some insight about this issue?
There's nothing special about HiDPI monitor.
That is what I thought until I saw Elyas' screenshot. I do not have Windows either though.
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 »

Elyas wrote: Fri Jan 15, 2021 1:22 pm
abdullah wrote: Fri Jan 15, 2021 1:07 pm
Resizing doesn't matter. But the ratio of icon and text sizes is important.
Screenshot_20210115_163447.png
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?
Elyas
Posts: 58
Joined: Fri Sep 04, 2020 12:25 pm

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

Post by Elyas »

abdullah wrote: Fri Jan 15, 2021 7:14 pm Is your monitor dpi anywhere around 170-180 dpi?
184
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 »

Elyas wrote: Fri Jan 15, 2021 7:32 pm
abdullah wrote: Fri Jan 15, 2021 7:14 pm Is your monitor dpi anywhere around 170-180 dpi?
184

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
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: Sat Jan 16, 2021 7:08 am
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.
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
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: Sun Jan 17, 2021 9:22 am
abdullah wrote: Sat Jan 16, 2021 7:08 am
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.
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
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...

It is perfectly fine to define requirements for coin and make a better coin :D :D :D
User avatar
chennes
Veteran
Posts: 3879
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 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:
50mmRectangle.png
50mmRectangle.png (11.06 KiB) Viewed 2079 times

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)
Chris Hennes
Pioneer Library System
GitHub profile, LinkedIn profile, chrishennes.com
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 »

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 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
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.
Though, in SoFont it says it's points:
This 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.
Coin3d fork specifies pixels in both SoFont and SoText2
https://coin3d.github.io/Coin/html/clas ... a9f336cdeb
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).
There's also The Inventor mentor book:
size (SoSFFloat)
for SoText2, the point size in printer’s points. For SoText3, the size in object
space units (default = 10.0).
So, apparently, it was meant to be points as in printer points as in 72 points per inch.

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.
Post Reply