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.
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
--
Best regards, Sergey.
