<Swing Dev> [9] Review request for 8170387: JLightweightFrame#syncCopyBuffer() may throw IOOBE

[Sergey Bylokhov]

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.