Hello Philip
Le 17/04/2020 à 21:08, Philip Race a écrit :
So if this is "always zero", for BufferedImage, why aren't we just
directly returning zero ?
For consistency with existing BufferedImage.getMinX() and getMinY()
method implementations. Those methods shall always return zero (this is
also stated in the specification), but BufferedImage implementation
nevertheless delegates to raster.getMinX() and getMinY(). The
BufferedImage constructor verifies that (raster.minX == 0 && raster.minY
== 0), but despite this restriction some BufferedImage methods are
implemented for arbitrary raster.minX and raster.minY values (see for
example getData() — note however that setData(Raster) is not robust to
arbitrary minX and minY).
I don't know why some (but not all) BufferedImage methods have been made
robust to arbitrary minX and minY. So for deciding what to put in
getTileGridXOffset(), I took the formula and substituted each term by
the corresponding BufferedImage implementation. This process was
documented in a previous version of this change request:
http://cr.openjdk.java.net/~serb/8166038/webrev.00/src/java.desktop/share/classes/java/awt/image/BufferedImage.java.udiff.html
I'm a bit on the fence about this wondering whether to submit a CSR
here, since a behavioural change is being introduced in order to
conform to the spec, and there is some compatibility issue possible.
Note that previous behavior was mathematically inconsistent with
RenderedImage specification and with Java Advanced Imaging (JAI)
implementation (e.g. PlanarImage.XtoTileX(int)). It went unnoticed maybe
because Java2D has optimization for the BufferedImage case which bypass
the getTileGridXOffset() and getTileGridYOffset() values.
Regards,
Martin
