On 11/29/2016 5:51 PM, Sergey Bylokhov wrote:
Hi, Semyon.
It is a little bit strange that the coordinates which were used to
create/recreate the image can produce IOOBE when we copy this image
later. It seems that we have loss of precision when we divide/multiply
coordinate by the scalefactor. Or probably the reason is that we use
the different "round" logic when we create the image and when we copy
the data? I guess that the "round" logic should be the same in both
cases, but I am not sure which one should be used. It is possible to
check it: if two JLightweightFrame will be created in a row and placed
one after another in the container. The correct behavior is that the
pixels between will not overlap or gaps will not exists(it will be
better if these components will have a semi-transparent colors).
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.
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
