On Fri, 5 May 2023 08:58:37 GMT, Martin Desruisseaux <[email protected]> wrote:
>> src/java.desktop/share/classes/java/awt/image/BufferedImage.java line 1523:
>>
>>> 1521: Rectangle bclip = new Rectangle(0, 0, raster.width,
>>> raster.height);
>>> 1522: Rectangle intersect = rclip.intersection(bclip);
>>> 1523: if (intersect.isEmpty()) {
>>
>> Does the "raster.setRect" has equivalent optimizations? it seems that method
>> implements handcrafter "intersection", any idea why it was implemented that
>> way?
>
> I do not know why `WritableRaster.setRect(Raster)` computes intersection with
> its own code in the method body instead of delegating to
> `Rectangle.intersection(Rectangle)` in the same way as
> `BufferedImage.setData(Raster)` does. For now I see no technical reason. I'm
> tempted to add a commit to this pull request for replacing the intersection
> calculation of `WritableRaster.setRect(Raster)`, but abstained for now
> because I though that reviewers or sponsors may want to minimize the changes.
> However I believe that this replacement would be desirable at least for the
> extra robustness of `Rectangle` regarding underflow and overflow.
Can we prove the overflow issue there by some test? If yes then probably it
would be useful to fix it as well, probably even as separate bug which can be
later backported.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13797#discussion_r1187770347
