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