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