Hi Alexandr,
Is the fully scaling code noticeably slower than the regular code? Is there a reason to test and only use it
conditionally? It shouldn't be a lot of overhead considering everything else that goes on during a repaint. Some of
the set/unset of attributes could also be optimized around the double for loop to help some.
...jim
On 10/6/16 10:07 AM, Alexandr Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8162350
webrev: http://cr.openjdk.java.net/~alexsch/8162350/webrev.00
The fix uses the solution suggest by Jim in the email:
http://mail.openjdk.java.net/pipermail/2d-dev/2016-October/007737.html
To draw to a VolatileImage backbuffer its graphics transform is set to
identity and device coordinates are used to set
the buffer clip.
Copying the backbuffer image to the graphics has some problems.
-------------
// Since there is no drawImage(img, float x, float y)...
destination.translate(pixelx1 / scaleX, pixely1 / scaleY)
destination.drawImage(img, 0, 0)
-------------
This code solves the problem for the top left corner of the region. All
Graphics.drawImage(...) methods scales the
image size and it looks like ceil(img.getWidth() * scaleX) can be differ from
the ceil(pixelx1 + img.getWidth() *
scaleX) - pixelx1 so the right bottom corner of the image does not fit the
required point.
There is also a question could a line drawn from one point and then from
another has a different width in pixels
because the graphics scale is not integer.
The proposed fix prepares a backbuffer with size [x + w, y + h] in a user
space and a component is drawn in to the
region [pixelx1, pixely1, pixely2, pixely2] in the device space.
After that the necessary clip is set to the graphics and whole image is just
drawn into it.
The new logic is used only the component graphics configuration is scaled the
graphics configuration has the same
scales. So it possible just to copy the backbuffer surface data to the graphics
surface data.
For other cases like for rotated graphics transform it seems it is necessary
to have more complicated algorithm.
This solves problems with repainted region but there are still artifacts with
JInternalFrame moving or a component
scrolling, This can be related to the RepaintManager.copyArea() method which
needs to be updated in the similar way. I
have created an issue on it:
JDK-8167305 RepaintManager.copyArea() method should be updated for floating
point UI scale
https://bugs.openjdk.java.net/browse/JDK-8167305
Thanks,
Alexandr.
