Hidpi, font&icon scaling, etc....

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
Posts: 399
Joined: Wed Oct 24, 2018 9:49 pm

Re: Hidpi, font&icon scaling, etc....

Postby vanuan » Wed Sep 16, 2020 9:35 pm

Elyas wrote:
Wed Sep 16, 2020 8:38 pm
Before your change the default font size for EditSketcherFontSize was 17 pixels. After your change the default font size is 12 pixels multiplied by the dpi scale factor. So, before it was 17 hardware pixels, after it is 12 device independent pixels.
The bug is:
If in Prefereces editSktcherFontSize = 17 (px - is it means pixels?)
According to the current code and screenshots, it is being used as pixels. Haven't you read SoFont class documentation? Do you see the "px" next to the "Sketcher - Sketch editing - Font size" number input?

Unfortunately, settings don't have units enforcement. So it's hard to detect when they are not properly used in code.
Elyas wrote:
Wed Sep 16, 2020 8:38 pm
The real font size in Sketcher window is not 17 pixels & not 17 points.(Coin font size - it is not pixels)
According to your screenshots, you set it to 25px. 17px is a default value. 25px is 18.75pt. But since you probably have HiDPI scaling enabled, that is factored by some constant (from 100% to 400%).

Coin font size is in pixels for 2D text (a SoText2 node).
Elyas wrote:
Wed Sep 16, 2020 8:38 pm
After my edits font size in window match preferences. (means pixels)
Is it wrong direction?
Well, when we speak of pixels, you have to specify whether those are device independent pixels or absolute pixels. Points are better because those are not ambiguous and related to inches on the screen or paper. While pixel meaning can change depending on the DPI scale factor.

It seems your solution is a hack: it works for your font settings / screen size / resolution / dpi scale ratio but you can't explain how and can't guarantee it would work for all users. Did you match it by eye? Or you can provide a formula to demonstrate that "editSketcherFontSize" is properly scaled to accommodate for HiDPI ratio?
Elyas wrote:
Wed Sep 16, 2020 8:38 pm

What do you suggest?
To define font size in Preferences as ponts - may be it right way. But this does not solve most of the questions.
Yes, specifying all font sizes in points and getting rid of any pixel settings should be the end goal for a proper HiDPI support.

On the wiki I provided a clear path to that state. All sizes in pixels should be either scaled by dpi ratio or calculated from the text size. All font sizes should be in points. If you need the font size in pixels, that should be calculated by taking into account the dpi ratio. If you need the font size to change dynamically when changing the window/elements size, that's a separate feature completely independent from HiDPI support.

Ideally, there should be only one setting - "base font size". And all the other font sizes should be specified in relative units - rems or ems. But probably it would be easier to implement in the browser-based UI.
Elyas wrote:
Wed Sep 16, 2020 8:38 pm
Neither before nor after the corrections the user has any control over the font size. There is no conflict. If you want to automatically scale the NaviCube dimensions, it is possible, but that is a different task. Matching the font size and cube should still be. Now it is being done wrong.
True, there's no separate setting to specify a font size for the cube. But there is a global setting to scale all the font sizes up or down. It is called "dpi scale ratio" and is available in the OS display settings. Qt supports this setting automatically, so developer doesn't have to do anything.

But Coin, unfortunately, doesn't support this. So the dpi scale ratio should be taken into account separately.

As I see from you code, you just changed some magic constant which I suppose was chosen arbitrarily. It doesn't seem to support HiDPI font scaling. So users with HiDPI will need to increase the cube size, while users with small resolution displays will need to decrease the cube size. This is a bad user experience. The default size should work nicely without any fiddling with settings for users with normal eye sight and an appropriate DPI ratio..