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
--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
