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