On 7/26/2016 9:16 PM, Sergey Bylokhov wrote:
On 26.07.16 13:55, Semyon Sadetsky wrote:
Debug scale should always be taken into account, if the text will be
small in this case then Xft.dpi should be ignored as I described
below. We should use only one property at a time.
I did not get, why in case of debug the GTK font size should be
decreased by scale times while size of all other fonts and interface
elements is being increased by scale times?
Why it should be decreased? it should work as other components. But we
should use only one source of system scale information at a time. And
debug scale should have the main priority. Xft.dpi should affect jdk
in the same way as "text-scale-factor, text-scaling-factor".
Please look at the code the fix is applied to. Native scale is in the
divider.
This fix is not related to the whole jdk scale it is only about GTK font
size.
Taking Xft.dpi as a global jdk scale (not in this fix, of cause) would
require an additional investigation. But the supported OSes provide
refined scale info from xsettings.
I think the logic should be:
- Take debug scale into account if it was set and skip all others.
- Check J2D_UISCALE
- Check scale-factor, text-scale-factor, text-scaling-factor.
- Check Xft.dpi.
- If non of them was set then scale=1 should be used.
Did you try to use scale from Xft.dpi? Its value is not a scale
usually.
What is the difference between text-scale-factor and Xft.dpi? Both of
them text related. But one of them is used as a general/default scale
of GC and another one affects the text only.
Anyway, the above is about a global scale, so it is unrelated to the
original issue which sounds like "Text size is twice bigger under GTK
L&F".
It is related since we should decide how and when to use Xft.dpi.
