Yes, most likely. It involves making sure that the origin of the viewport is always an even multiple of pixels, then
the copyArea will match up with the repainting. The damage repair messages here have already pointed out how to deal
with making sure the repaints are on integer coordinates, the only tricky part is that there is no floating point
copyArea method (copyArea used to not allow copying with anything other than a translation, but we fixed that for Mac,
but the fix really only works for integer scales and, while it does do something sane for non-integer scales, it doesn't
really provide the caller full precision for controlling which pixels are copied). To do a pixel-exact copyArea you
would need to undo the transform, calculate the scaled pixel locations yourself, then do a non-scaled copyArea and then
restore the transform (or do the operation on a copy of the graphics)...
...jim
On 10/6/16 3:11 AM, Anton Tarasov wrote:
Hi all,
On 04 Oct 2016, at 23:28, Jim Graham <james.gra...@oracle.com> wrote:
On 10/4/16 1:01 PM, Anton Tarasov wrote:
Anyway, I roughly tried your approach mentioned in the previous e-mail, but
forcing RM to paint via offscreen
BufferedImage, not volatile (just for a quick check).
It solved the shift issue of the demo listed in 8162350, which is cool. It also
solved the traces of InternalFrame and
menu in SwingSet2. Scrolling still traces (I suppose it should be resolved in
JViewport/blitting).
Also, the problem with primitives rendering
(http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is
still there. But it seems to relate to line-thikness (border-thickness)
rounding inaccuracy. What we can do with that?...
Yes, blitting is a separate, but related case where pixel-exactness matters.
When we scroll a pane we need to scroll it by a precise number of pixels and
then paint the newly visible information at a precise pixel location. Solving
this aspect might require events to have higher precision data available.
We should probably take detailed conversations about the solutions to the bug
reports…
What do you think, is it possible to address the mentioned issues in jdk9, not
deferring them? The new HiDPI support will affect all the users having
fractional scale screens...
Thanks,
Anton.
