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

Semyon Sadetsky semyon.sadetsky at oracle.com
Tue Nov 29 15:50:08 UTC 2016


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




More information about the swing-dev mailing list