+1. Thanks, Jay
> On 28-Jul-2020, at 9:56 AM, Sergey Bylokhov <sergey.bylok...@oracle.com> > wrote: > > The new version of the fix: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166038 > Fix: http://cr.openjdk.java.net/~serb/8166038/webrev.02 > > In the new version, the test was updated based on the feedback. > > On 01.04.2020 19:51, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk/client. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8166038 >> Fix: http://cr.openjdk.java.net/~serb/8166038/webrev.00 >> The fix contributed by Martin Desruisseaux. >> Initial discussion about the bug: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-February/010576.html >> Implementation of getTileGridXOffset() and getTileGridXOffset() in >> BufferedImage seems in contradiction with specification. The >> RenderedImage specification said: >> Returns the X offset of the tile grid relative to the origin, i.e., >> the X coordinate of the upper-left pixel of tile (0, 0). (Note that >> tile (0, 0) may not actually exist.) >> Since BufferedImage has only one tile, always at index (0,0), the (x,y) >> coordinates of the upper-left pixel of that tile should be the image >> (minX, minY), which is always (0,0) in a BufferedImage. Indeed >> BufferedImage.getTileGridXOffset() javadoc adds the following sentence: >> This is always zero. >> But the BufferedImage implementation is: >> public int getTileGridXOffset() { >> return raster.getSampleModelTranslateX(); >> } >> Which does not always returns zero. > > > -- > Best regards, Sergey. >
