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

Sergey Bylokhov sergey.bylokhov at oracle.com
Tue Dec 6 20:01:30 UTC 2016


>> 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.

Looks fine to me. I hope Jim can double check this round logic.


>> 
>> 
>>>> 
>>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20161206/59ba8488/attachment.html>


More information about the swing-dev mailing list