RFR: 8357299: Graphics copyArea doesn't copy any pixels when there is overflow

Prasanta Sadhukhan psadhukhan at openjdk.org
Mon May 26 02:49:58 UTC 2025


On Fri, 23 May 2025 20:59:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Graphics copyArea overflow check bails out of copying pixels if there is overflow.
>> The spec says ""If a portion of the source rectangle lies outside the bounds of the component, or is obscured by another window or component, {@code copyArea} *will be unable to copy* the associated pixels"
>> 
>> which suggests that we should always copy the parts inside the bounds and never the parts outside the bounds
>> but it seems currently, in the case of overflow it no longer copies any pixels, including the parts that are inside. 
>> So, the fix clips the copyarea region to clip bounds so it will only affect pixels within the valid bounds, and any pixels outside will be ignored.
>
> src/java.desktop/share/native/libawt/java2d/loops/Blit.c line 85:
> 
>> 83:     dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)
>> 84:                         ? clipInfo.bounds.x2 : (dstx + width);
>> 85:     dstInfo.bounds.y2 = UNSAFE_TO_ADD(dsty, height)
> 
> why wouldn't you always want to limit it to the clip ?
> I mean shouldn't it be like this ?
> dstInfo.bounds.x2 = UNSAFE_TO_ADD(dstx, width)  ? clipInfo.bounds.x2 : (((dstx + width) > clipInfo.bounds.x2) ? clipInfo.bounds.x2 : (dstx + width));
> or maybe a bit more readable as 
> dstInfo.bounds.x2 = ((UNSAFE_TO_ADD(dstx, width) || ((dstx + width) > clipInfo.bounds.x2)) ? clipInfo.bounds.x2 : (dstx + width);

That is because down below it anyway calls
`SurfaceData_IntersectBounds(&dstInfo.bounds, &clipInfo.bounds); `
so it should clip to clipInfo.bounds there I presume..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25340#discussion_r2106426836


More information about the client-libs-dev mailing list