<Swing Dev> [9] Review request for 8058742: Text size is twice bigger under GTK L&F on Gnome with HiDPI enabled
Semyon Sadetsky
semyon.sadetsky at oracle.com
Mon Jul 25 11:25:10 UTC 2016
On 7/25/2016 1:46 PM, Alexandr Scherbatiy wrote:
> On 7/25/2016 12:18 PM, Semyon Sadetsky wrote:
>>
>>
>> On 7/25/2016 11:02 AM, Alexandr Scherbatiy wrote:
>>> On 7/22/2016 10:27 PM, Semyon Sadetsky wrote:
>>>>
>>>>
>>>> On 7/22/2016 8:54 PM, Alexandr Scherbatiy wrote:
>>>>> On 7/21/2016 7:04 PM, Semyon Sadetsky wrote:
>>>>>>
>>>>>>
>>>>>> On 21.07.2016 18:33, Alexandr Scherbatiy wrote:
>>>>>>> On 7/21/2016 1:40 PM, Semyon Sadetsky wrote:
>>>>>>>> On 7/21/2016 1:24 PM, Sergey Bylokhov wrote:
>>>>>>>>
>>>>>>>>> On 21.07.16 13:18, Semyon Sadetsky wrote:
>>>>>>>>>> We do not support non-integer scale on Linux.
>>>>>>>>>
>>>>>>>>> If it is unsupported then why it is validated in the pango
>>>>>>>>> fonts and not in X11GraphicsDevice? I am not sure how scale
>>>>>>>>> less than 1 prevent us from usage of 1.5 for example.
>>>>>>>> getNativeScale() returns int. int cannot be 1.5.
>>>>>>>
>>>>>>> The fix JDK-8149115 "[hidpi] Linux: display-wise scaling
>>>>>>> factor should probably be taken into account" allows to read the
>>>>>>> UI scale factor from some system properties like J2D_UISCALE and
>>>>>>> com.ubuntu.user-interface scale-factor. Could they have floating
>>>>>>> point values?
>>>>>> On the native side they are floating point. But since we do not
>>>>>> support floating point scale on linux they are rounded to integer.
>>>>>>> How do they relate to the "gnome.Xft/DPI" property from the
>>>>>>> PangoFonts? Is it possible that the "gnome.Xft/DPI" value is
>>>>>>> 192 which corresponds to 2x HiDPI display and the J2D_UISCALE is
>>>>>>> set to 3?
>>>>>> gnome.Xft/DPI is set by desktop env. Usually it corresponds the
>>>>>> system scale from gsettings db. But I cannot guarantee this for
>>>>>> any WM/desktop combinations.
>>>>>> J2D_UISCALE variable is only for java, it may be set to any value
>>>>>> and it is unrelated to the native scale.
>>>>>
>>>>> May be it is better to include the "gnome.Xft/DPI" scale to the
>>>>> X11GraphicsDevice.getNativeScaleFactor(screen) method. Right now
>>>>> only GTK L&F uses it but may be others L&F also should be scaled
>>>>> according to this value.
>>>> From [1]: If you are not using a desktop environment such as GNOME,
>>>> KDE, Xfce, or other that manipulates the X settings for you, you
>>>> can set the desired DPI setting manually via the Xft.dpi variable
>>>> in ~/.Xresources.
>>>> JDK9 supported DEs manage scale in own settings and Xft/DPI is
>>>> calculated from those settings. Also Xft/DPI is only for fonts, not
>>>> for interface elements.
>>>> That may be not easy to get this property per individual monitor.
>>>> Also it is an relative DPI value and the real scale need to be
>>>> restored somehow.
>>>>
>>>> [1] https://wiki.archlinux.org/index.php/HiDPI
>>> There is one thing which is not clear for me. Where is the place
>>> that GTK font size is multiplied on the
>>> X11GraphicsDevice.getNativeScaleFactor(screen) the second time?
>> One time is in the PangoFont ( dsize = ((double)(dpi * size)/
>> 72.0);), the second time in the graphics transformation if it uses
>> the native scale.
>
> Let's run a java application with the debug scale 5
> (-Dsun.java2d.uiScale=5) and GDK_SCALE system environment set to 2.
> The X11GraphicsDevice.getNativeScale() should be 2 (GDK_SCALE) and the
> PangoFonts.fontScale should be 5 (the debug scale from the
> GraphicsConfiguration.getDefaultScreenDevice().getDefaultConfiguration()).
>
> There are 2 formulas for the font size in the PangoFonts
> dsize = ((double)(dpi * size) / 72.0 / nativeScale); //
> "gnome.Xft/DPI" is set
> dsize = size * fontScale; // "gnome.Xft/DPI" is not set
>
> In the first case the size is divided by the nativeScale and then is
> multiplied by the fontScale (scale from the graphics configuration) in
> the Graphics. The final result is size * (dpi / 72) * fontScale /
> nativeScale = size * (dpi / 72) * 5 / 2. Probably it should be
> multiplied only on the fontScale in the graphics.
>
> In the second case dsize = size * fontScale which is multiplied by
> the fontScale in the graphics one more time. May be the fontScale
> should be omitted for this case in the PangoFonts.
Second case is not considered in this fix. Since Xft/DPI is set for all
supported Linux OSes, the second branch is never executed.
--Semyon
>
> Thanks,
> Alexandr.
>
>>
>> --Semyon
>>> The one place is the Graphics which gets additional scale factor
>>> from a GraphicsConfiguration. What is another place where the font
>>> is scaled using the native scale factor?
>>>
>>> Thanks,
>>> Alexandr.
>>>>
>>>> --Semyon
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 21.07.2016 13:13, Sergey Bylokhov wrote:
>>>>>>>>>>> Is it intended to skip scales less than 1?
>>>>>>>>>>>
>>>>>>>>>>> On 07.07.16 10:01, Alexandr Scherbatiy wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> The fix looks good to me.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>
>>>>>>>>>>>> On 7/6/2016 10:03 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>>> On 7/6/2016 6:03 PM, Alexandr Scherbatiy wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/6/2016 4:13 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058742
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.00/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - PangoFonts class is placed in the shared space and
>>>>>>>>>>>>>> it uses the
>>>>>>>>>>>>>> X11GraphicsDevice from the unix space. Could there be
>>>>>>>>>>>>>> problems with
>>>>>>>>>>>>>> build compilation on platforms differ from Unix?
>>>>>>>>>>>>> no it doesn't cause compilations problems. PangoFonts is
>>>>>>>>>>>>> used on Linux
>>>>>>>>>>>>> platform only.
>>>>>>>>>>>>>> - It is better to rename the scale field to nativeScale
>>>>>>>>>>>>>> just to not
>>>>>>>>>>>>>> mix it with other scale types
>>>>>>>>>>>>> ok. webrev is updated:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8058742/webrev.01/
>>>>>>>>>>>>>> - Does the test
>>>>>>>>>>>>>> test/java/awt/font/FontScaling/FontScalingTest.java fails
>>>>>>>>>>>>>> without
>>>>>>>>>>>>>> the proposed fix on Linux?
>>>>>>>>>>>>> Yes it fails before and passes after the fix.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After adding hdpi support to JDK the GTK LnF fonts are
>>>>>>>>>>>>>>> scaled twice
>>>>>>>>>>>>>>> using the JDK UI scale factor and the native scale
>>>>>>>>>>>>>>> factor derived
>>>>>>>>>>>>>>> from the screen dpi setting. The fix removes the native
>>>>>>>>>>>>>>> scale if it
>>>>>>>>>>>>>>> is already taken into account in the JDK UI scale.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the swing-dev
mailing list