Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/
- pixbuf is freed in the awt_Robot.c
- screenWidth/Height is rescaled in the XToolkit.initScreenSize() method
See more comments inline:
On 10/23/2015 7:55 AM, Jim Graham wrote:
On 10/22/2015 5:07 PM, Jim Graham wrote:
I'm guessing that 6356322 has been fixed?
Yes.
In XComponentPeer we shouldn't be scaling a region, we should have
created the region in a scaled coordinate system...
Could you give more details on this?
For example, we create a frame which is twice bigger than the
original one for the scale 2.
For this case it needs to scale the shape twice. The lox, loy,
hix, hiy values are calculated correctly.
The native function XShapeCombineRectangles is used to draw the
final shape for the given window.
In XDragSourceContextPeer, should the scaledown try to do rounding?
Also, XMouseInfoPeer, lines 71,72?
Also, XToolkit, lines 725,726,855-858?
Also, XlibUtil, lines 129-131,159?
Also, X11GraphicsConfig, line 272?
I changed this to use scaleDown(x, scale) method from the XlibUtil.
However, I am not sure about rounding. Only integer scale values
can be used. In this case x / 2 (3, 4, ...) returns a rounding to the
smallest value
which is what we probably need.
awt_GraphicsEnv.c - what about GDK_DPI_SCALE? It seems like it might be
used to compensate for fonts on HiDPI screens that are already scaled
for the DPI, but if you honor GDK_SCALE then you will doubly-scale the
fonts. I'm not entirely sure I understand that, though, but it bares
further investigation...
https://bugs.openjdk.java.net/browse/JDK-8058742
may be related to this GDK_DPI_SCALE issue...
I think yes. The GDK_DPI_SCALE can be used in the JDK-8058742 fix
to rescale GTK L&F UI sizes so they look in the same way as other L&Fs.
And the GDK_SCALE is used in the current fix to scale all UI.
It looks like there is no need to use the GDK_DPI_SCALE in the
current fix and I would prefer to not mix the current fix with the
JDK-8058742.
...jim
Also, is GDK_SCALE the only platform scale factor that Linux/X11
might use?
I used only GDK_SCALE in this fix. If there is another scale
factors it would be better to add them in another fix.
awt_Robot.c, line 280 - you lose the pointer to the old pixbuf, but
shouldn't both be freed?
I have updated this.
awt_Robot.c, just verifying what I'm seeing - that if GTK operations
fail then we use nearest neighbor scaling in the X11 backup code, right?
Yes.
gtk2_interface.h - isn't that a fragile connection to the gtk library to
declare our own enum and assume that the compilers will use the same
values?
That is what gtk2_interface.h does for all enums to avoid explicit
dependencies to the GTK lib.
If there is a better solution, it can be considered in a separate fix.
Thanks,
Alexandr.
...jim
On 10/22/15 7:03 AM, Alexander Scherbatiy wrote:
On 10/10/2015 3:16 AM, Jim Graham wrote:
Hi Alexandr,
Is it possible to create a diff of this without the fixes from 8073320
mixed in? This bug is really just focused on the Linux support of
that other framework, right?
Here is the webrev which contains only the Linux changes:
http://cr.openjdk.java.net/~alexsch/8137571/webrev.01
Thanks,
Alexandr.
...jim
On 10/5/15 7:01 AM, Alexander Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8137571
webrev: http://cr.openjdk.java.net/~alexsch/8137571/webrev.00
This is an initial part of the HiDPI Graphics support on Linux for
the JEP 263: HiDPI Graphics on Windows and Linux
http://openjdk.java.net/jeps/263
- scale factors are added to surface dates
- window size and events coordinates are scaled on peer side
- XRobotPeer mouseMove() and getRGBPixel() methods are updated
- GDK_SCALE system variable is used to detect the scale factor in
GTK+
- "sun.java2d.uiScale.enabled", and "sun.java2d.uiScale"
options are
added for the testing purposes
- some classes like LWWindowPeer, SurfaceManager, SunGraphics2D,
DrawImage, SurfaceData are just the same as in the fix for HiDPI
Graphics support on Windows
Thanks,
Alexandr.
