On 11/29/2016 7:59 PM, Sergey Bylokhov wrote:
On 29.11.16 18:50, Semyon Sadetsky wrote:
I did not get this. The area doesn't determine any sizes or location on
screen. It's simply an optimization to update area of the buffer image
which was really changed. It cannot be bigger than the buffer image
size. The logic of the rounding is to "inflate" the rectangle area to
its next integer coordinates in all directions. With other rounding
logic you will see artifacts with non-integer scales.
you add this code to the fix:
302 int linestride = bbImage.getWidth();
+308 if (startX + width > linestride) {
+309 width = linestride - startX;
+310 }
the x,y,w,h passed to the method are inside the bounds of the
component. so the simple expectation which can be done is that
R(x*scale),R(x*scale),R(y*scale),R(w*scale),R(h*scale) should be
inside the image which was created in resizeBuffer():
BufferedImage(R(imgW), R(imgH)). where the "R" is a round operation.
But for some reason the size of the image is smaller, I guess this is
because resizeBuffer() use Math.round() and syncCopyBuffer() uses
ceil+floor.
No. In most cases this method is called for area less than buffer image
size. Global repaint is also possible but it is not often happens,
usually on window resize.
Since ceil() is used in JDK as coordinates rounding method it should be
used here as well to obtain the maximum repainted area bounds in integer
coordinates. But for the global size the round() is used, because the
image should fit the external size which uses another coordinates
rounding approach.
On 28.11.16 16:50, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8170387
webrev: http://cr.openjdk.java.net/~ssadetsky/8170387/webrev.00/
After the rounding the resulting rectangular area may became bigger
than
the buffer image size and this will cause IOOB error during the
consequent System#arraycopy() calls. To prevent this error the updated
area is bounded to the buffer image size.
--Semyon
