[Bf-committers] Automatic DPI detection issues

Ton Roosendaal ton at blender.org
Thu Jul 13 19:04:55 CEST 2017


Hi,

I happen to know that Brecht visits us (and Sergey) early next week, so we can discuss it in person. :)

In general: when OS's give a reliable DPI setting, which applications are supposed to follow, we can do as well. Nothing against following such OS settings.

If that feature breaks (changes) how Blender works, it better be in 2.8. If it's a new feature that will keep Blender work as usual (without having to do something), it's fine for 2.79. 

That's what everyone agrees on, right? 

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation, Director Blender Institute
Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands



> On 13 Jul 2017, at 18:13, Brecht Van Lommel <brechtvanlommel at pandora.be> wrote:
> 
> You're the first to report this blurry fonts bug after the change has been
> there for 4 months and has been tested by many people. It works fine here
> on a 2K and 4K monitor on Linux, with various window managers. Obviously
> I'll fix the bug, and if there is a deeper design issue we can discuss that
> as well, but I think we're mixing up the two.
> 
> Secondly, whether it's a good thing or not, Windows and Linux do use the
> "DPI" to scale UIs up and down. The "DPI" does not just represent the
> dots-per-inch of the monitor, it includes a user specified scaling factor
> as well. There is no distinction between the two, and even if there was,
> Freetype hinting is not significantly affected by it.
> 
> On Windows and Linux the convention is that DPI 96 is a "normal" size,
> while on macOS is the convention is DPI 72. Blender was coded for 72, so we
> convert to that.
> 
> 
> On Thu, Jul 13, 2017 at 5:52 PM, Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
> 
>> Hi,
>> 
>> Well, sure there is SOME control. But i'm still not sure how would one get
>> a proper value to make his font look properly without doing `<good_dpi> /
>> C.user_preferences.system.dpi` oneliner in python console (which is
>> obviously something i would not advertise as an official way of getting
>> Blender's interface looking good).
>> 
>> Further, both xdpyinfo and X log tells me i'm on 96 DPI now (i forced it in
>> xorg.conf to get reasonable Blender interface). However,
>> the C.user_preferences.system.dpi reports DPIU of 72. Is it called
>> reliable? Or are you internally "normalizing" it to Blender's default 72
>> (without mentioning this in the comment of dpi property) ?
>> 
>> And even further, you never use DPI for scaling fonts up. You modify font
>> size for that, keeping DPI on the exact value of your monitor. Otherwise
>> you're running the whole idea of subpixel rendering. So i've got no idea
>> how you can use same slider to both scale interface up and down and
>> compensate for a badly detected DPI.
>> 
>> On Thu, Jul 13, 2017 at 5:32 PM, Brecht Van Lommel <
>> brechtvanlommel at pandora.be> wrote:
>> 
>>> Right, this is respecting the setting that the user configured in the OS.
>>> And then on top of that we provide an additional Blender UI scale so no
>>> control is lost.
>>> 
>>> Also note that a relative scale is important when there are two screens
>>> with different DPI (e.g. laptop and external monitor). Previously such a
>>> setup was quite unusable on Windows.
>>> 
>>> On Thu, Jul 13, 2017 at 5:09 PM, Julian Eisel <eiseljulian at gmail.com>
>>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I'm definitely in favor of the change from having an absolute DPI user
>>>> setting in Blender to having an OS relative one.
>>>> 
>>>>> - This is totally unpredictable, changes Blender interface based on
>>> some
>>>> rather random factors.
>>>> Where are those factors random? It keeps backwards compatibility if
>>>> needed, otherwise it just uses the OS setting.
>>>> 
>>>>> - Blender does not tell user what DPI it detected (yes, the commit
>>>> removed setting from User Preferences)
>>>> Why should a user care? All the user cares about is is if things look
>>>> too small, too big or just fine. The UI is not printed to paper or
>>>> something.
>>>> 
>>>>> - If system reports buggy DPI, there is no easy way to know what's
>>>> causing it and how to correct.
>>>> That was a concern I had too, but apparently it works quite reliable.
>>>> You can still tweak the UI scale if something doesn't look correctly.
>>>> 
>>>>> Any feature that attempts to automatically guess user needs is due to
>>>> failure.
>>>> This is not attempting to guess anything automatically. This is an OS
>>>> wide option, with reasonable defaults and users have full control over
>>>> it. Why should you have to set this again in Blender? Why should
>>>> Blender ignore this OS wide setting while most other apps (that care
>>>> about UX) use it? It's just a redundant setting and redundant info.
>>>> 
>>>> So I agree with Brecht here: if there are issues with font drawing
>>>> then it's probably the font drawing itself that scales badly, the OS
>>>> DPI should be fine.
>>>> 
>>>> Also, Jonathan Williamson gave feedback on this as well:
>>>> https://developer.blender.org/D2539#59872
>>>> 
>>>> Cheers,
>>>> - Julian -
>>>> 
>>>> On 13 July 2017 at 16:45, Ton Roosendaal <ton at blender.org> wrote:
>>>>> Hi,
>>>>> 
>>>>> Any feature that attempts to automatically guess user needs is due to
>>>> failure.
>>>>> The only automatic DPI setting I would accept is to detect High DPI
>>>> screens (4k or more).
>>>>> 
>>>>> -Ton-
>>>>> 
>>>>> --------------------------------------------------------
>>>>> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
>>>>> Chairman Blender Foundation, Director Blender Institute
>>>>> Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 13 Jul 2017, at 16:25, Brecht Van Lommel <
>>> brechtvanlommel at pandora.be>
>>>> wrote:
>>>>>> 
>>>>>> Then I think the real issue is that Blender fonts draw blurry below
>> a
>>>>>> certain size. It seems to happen when changing the DPI, but also
>> when
>>>>>> changing the font size or zooming.
>>>>>> 
>>>>>> So I think the solution is to either solve that problem (not sure if
>>>> it's
>>>>>> something that can be tweaked in font drawing or would need a
>>> different
>>>>>> font), or work around it by biasing the auto DPI a bit towards 92.
>>>>>> 
>>>>>> On Thu, Jul 13, 2017 at 2:37 PM, Sergey Sharybin <
>>> sergey.vfx at gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Answers are inlined.
>>>>>>> 
>>>>>>> It the UI is too small you scale it up, if it's too big you scale
>> it
>>>> down?
>>>>>>>> 
>>>>>>> 
>>>>>>> Is this interface too small or too big:
>>>>>>> http://pasteall.org/pic/show.php?id=117179
>>>>>>> 
>>>>>>> What should i put to a Scale factor to make it proper "kerning" ?
>>>>>>> 
>>>>>>> It's not clear to me what you mean by improperly displayed fonts
>>> here,
>>>> I
>>>>>>>> tried various DPI values in 2.78 and various UI scale values in
>>> master
>>>>>>> and
>>>>>>>> the fonts always look ok to me.
>>>>>>>> 
>>>>>>> 
>>>>>>> Just force getDPIHint() to return 88 and see font artifacts,
>> similar
>>>> to the
>>>>>>> screenshot above.
>>>>>>> 
>>>>>>> 
>>>>>>>>> - Not reporting detected DPI is also wrong.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I don't know of any other application reporting this in the UI,
>> why
>>>> does
>>>>>>>> the absolute value matter to the user?
>>>>>>>> 
>>>>>>> 
>>>>>>> Maybe because other applications are not failing that badly on
>>>> displaying
>>>>>>> good fonts by default?
>>>>>>> 
>>>>>>> 
>>>>>>>>> - Not being able to correct auto-detected DPI also sounds wrong.
>>> All
>>>>>>> the
>>>>>>>> DE
>>>>>>>>> will have option to override X11 DPI specifically for the case
>> when
>>>> X11
>>>>>>>>> reports wrong DPI.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Again, it can be corrected by changing the UI scale. This is fully
>>>>>>>> equivalent to adjusting the DPI value.
>>>>>>>> 
>>>>>>> 
>>>>>>> With the difference that i do have a remote idea what my DPI should
>>>> be, but
>>>>>>> i've got no idea what should be the scaling factor to compensate
>>> badly
>>>>>>> working fonts in Blender.
>>>>>>> 
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> P.S. I wouldn't know if other applications are detecting DPI
>>>> correctly
>>>>>>>> (as
>>>>>>>>> in, not sure they are using crappy DPI of 88x89 or are rounding
>> it
>>> to
>>>>>>>> some
>>>>>>>>> more commonly used DPI), but it's only Blender which has badly
>>>> rendered
>>>>>>>>> fonts on my system.
>>>>>>>>> P.P.S. Surely i can force/correct X11/DE's DPI, but then i don't
>>> see
>>>>>>> any
>>>>>>>>> benefit on the auto-detection of DPI. It only causes issues
>> rather
>>>> than
>>>>>>>>> solving anything.
>>>>>>>>> 
>>>>>>>>> On Thu, Jul 13, 2017 at 1:15 PM, Brecht Van Lommel <
>>>>>>>>> brechtvanlommel at pandora.be> wrote:
>>>>>>>>> 
>>>>>>>>>> As mentioned in the commit log, the UI Scale setting in the
>>>> Interface
>>>>>>>> tab
>>>>>>>>>> can be used, doesn't that work?
>>>>>>>>>> 
>>>>>>>>>> If you look at the equivalent settings for
>>>>>>> Windows/macOS/Gnome/Unity/..
>>>>>>>>>> they also offer a scale or percentage. I see no reason to show
>> the
>>>>>>>>> absolute
>>>>>>>>>> DPI.
>>>>>>>>>> 
>>>>>>>>>> Linux doesn't have a single window manager standard for
>> specifying
>>>>>>> DPI,
>>>>>>>>> but
>>>>>>>>>> we use the same convention as Chrome or Firefox which works in
>>> many
>>>>>>>>> window
>>>>>>>>>> managers, it certainly isn't random. Are you saying the DPI is
>> not
>>>>>>>> being
>>>>>>>>>> detect correctly on your system, while it works in other
>>>>>>> applications?
>>>>>>>>>> Perhaps we can fix that?
>>>>>>>>>> 
>>>>>>>>>> On Thu, Jul 13, 2017 at 12:32 PM, Sergey Sharybin <
>>>>>>>> sergey.vfx at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Hi everyone,
>>>>>>>>>>> 
>>>>>>>>>>> Today i've run into annoying/hard to predict situation: running
>>> my
>>>>>>>>>> regular
>>>>>>>>>>> blender was working fine, but doing --factory-startup was
>> messing
>>>>>>> up
>>>>>>>>>> fonts
>>>>>>>>>>> in Blender's interface.
>>>>>>>>>>> 
>>>>>>>>>>> it turns out, this commit is responsible for such behavior [1].
>>>>>>>>>>> 
>>>>>>>>>>> What happens is, when there is existing user-preferences.blend,
>>>>>>>> Blender
>>>>>>>>>>> will use DPI stored in there. Otherwise, Blender will use
>>>>>>>> auto-detected
>>>>>>>>>>> DPI. This has following issues:
>>>>>>>>>>> 
>>>>>>>>>>> - This is totally unpredictable, changes Blender interface
>> based
>>> on
>>>>>>>>> some
>>>>>>>>>>> rather random factors.
>>>>>>>>>>> - Blender does not tell user what DPI it detected (yes, the
>>> commit
>>>>>>>>>> removed
>>>>>>>>>>> setting from User Preferences)
>>>>>>>>>>> - If system reports buggy DPI, there is no easy way to know
>>> what's
>>>>>>>>>> causing
>>>>>>>>>>> it and how to correct.
>>>>>>>>>>> 
>>>>>>>>>>> So i think we should bring DPI setting back to user
>> preferences.
>>> It
>>>>>>>> is
>>>>>>>>>>> really bad practice to secretly use setting, without even
>> telling
>>>>>>>> what
>>>>>>>>>> the
>>>>>>>>>>> value of the setting is. It is also bad practice to auto-detect
>>>>>>>>> something
>>>>>>>>>>> and not give any clues to user what the detected value is. And
>>>>>>>> finally,
>>>>>>>>>>> there should be a way to override auto-detected DPI, for the
>>> exact
>>>>>>>> case
>>>>>>>>>>> when the reported one is bad.
>>>>>>>>>>> 
>>>>>>>>>>> [1] https://developer.blender.org/rBfe3fb23
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> With best regards, Sergey Sharybin
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Bf-committers mailing list
>>>>>>>>>>> Bf-committers at blender.org
>>>>>>>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Bf-committers mailing list
>>>>>>>>>> Bf-committers at blender.org
>>>>>>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> With best regards, Sergey Sharybin
>>>>>>>>> _______________________________________________
>>>>>>>>> Bf-committers mailing list
>>>>>>>>> Bf-committers at blender.org
>>>>>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Bf-committers mailing list
>>>>>>>> Bf-committers at blender.org
>>>>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> With best regards, Sergey Sharybin
>>>>>>> _______________________________________________
>>>>>>> Bf-committers mailing list
>>>>>>> Bf-committers at blender.org
>>>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> Bf-committers mailing list
>>>>>> Bf-committers at blender.org
>>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>>> 
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>>> 
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-committers
>>> 
>> 
>> 
>> 
>> --
>> With best regards, Sergey Sharybin
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-committers
>> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers



More information about the Bf-committers mailing list