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 provided fix.
The XGraphicsConfiguration bounds are also rescaled.
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 be a more accurate way to handle
applyShape(Region) at the device scale.
- DPI_SCALE needs to be handled eventually, don't let it fall through
the cracks
- Other Linux DPI attributes should be handled, hopefully there is a
bug filed for that
Some of those could be simply left for feedback from developers, but
what is our plan to get our developers to do a decent amount of
testing with their applications to let us know if our choices were fine?
More comments inline below:
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.initScreenSize()
method
Is there also a position that needs to be adjusted? Is the convention
that all screens should be directly adjacent, or can they float with
gaps between them?
The toolkit does not provide method to get the primary screen position.
I thought about adjusting screens with different scaling but it
looks like it is an additional task which can be handled in a separated
bug.
See more comments inline:
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.
I suppose it may be architecturally difficult to do at this point, but
ideally a Region should be a create-only structure that is produced at
the desired device coordinate system and scaling. It might be
necessary to perform integer translates on it as windows are moved
around the screen from one integer location to another, but it should
never be scaled. The fact that there is a method that can scale a
region is basically an admission that we have not always done the
right thing with respect to creating regions at device resolution.
It looks like this may be the path of least resistance currently, but
if we can improve the architecture to allow the Region to maintain
full device resolution and not require any scaling that would be far
better.
I see now.
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.
The fact that only integer scaling values can be used only makes
scaling up easier. It still begs the question of what value to report
when we end up with X.5 or X.75 - should that be X or X+1?
Why is truncation/rounding down what we need? Where is the analysis
of how application behavior will be affected by rounding down vs.
rounding up or rounding evenly?
Note that in FX we have a number of different coordinate snapping
functions that perform different rounding operations. Some are for
sizes of things, some are for locations, and some are for calculating
distributed distances during layout.
It could be better to move the question about location, sizes and
distances scaling to a separate bug. The same question I also have for
the Windows HiDPI Graphics support.
Thanks,
Alexandr.
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.
OK, as long as we are aware of it and tracking it. It sounds like
GDK_SCALE and GDK_DPI_SCALE come as a pair so I would have thought
that they'd be implemented as part of the same fix, but as long as we
get to it sooner rather than later, that's fine.
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.
True. I included this link in my HiDPI talk which appears to be a
fairly comprehensive list:
https://wiki.archlinux.org/index.php/HiDPI
...jim
