This version looks fine.
A few notes which we discussed offline:
- It will be good to understand how SG2D.copyarea should work in case of
transformed graphics.
- The different types of embedding should be checked(plugin,swt,fx).
- I suggest to run some benchmarks to figure out what performance
I think this can be good to go, but file some issues for further
investigation:
- scaling in applyShape()
- GDK_DPI_SCALE (though it may get handled under the other bug, maybe
add a comment there)
- Other Linux DPI properties to support
And while we probably don't need an issue submitted unti
On 11/10/15 5:07 AM, Alexander Scherbatiy wrote:
On 11/6/15 2:00 AM, Alexander Scherbatiy wrote:
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.initScre
On 11/7/2015 3:56 AM, Jim Graham wrote:
It looks like the only remaining issues are:
- Should we scale the origin of the screens so that they remain adjacent?
The Toolkit defines only methods that allows to get size of the the
primary screen and screen insets which are rescaled in the pro
It looks like the only remaining issues are:
- Should we scale the origin of the screens so that they remain adjacent?
Questions that remain and may end up getting handled under followon bugs:
- We should really think through rounding issues better in scaleDown()
- We need to see if there can b
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:0
Hi, Alexander.
I see that in a few places you have made a change:
Toolkit.getDefaultToolkit().getScreenSize();
to
getGraphicsConfiguration().getBounds();
My first impression was that you fix some bug related to multi-monitor.
But it seems because the GC.getBounds() uses correct downscaled bounds,
On 10/22/2015 5:07 PM, Jim Graham wrote:
I'm guessing that 6356322 has been fixed?
In XComponentPeer we shouldn't be scaling a region, we should have
created the region in a scaled coordinate system...
In XDragSourceContextPeer, should the scaledown try to do rounding?
Also, XMouseInfoPeer, l
I'm guessing that 6356322 has been fixed?
In XComponentPeer we shouldn't be scaling a region, we should have
created the region in a scaled coordinate system...
In XDragSourceContextPeer, should the scaledown try to do rounding?
Also, XMouseInfoPeer, lines 71,72?
Also, XToolkit, lines 725,726,
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:
htt
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?
...jim
On 10/5/15 7:01 AM, Alexander Scherbatiy wrote:
Hello,
Could you review the fi
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.jav
12 matches
Mail list logo
