Ping on behalf of David. Our current 8u222 solution would be to revert the patch for https://bugs.openjdk.java.net/browse/JDK-8221166 (which is the 8u222 backport issue for https://bugs.openjdk.java.net/browse/JDK-8048782).
Thanks, Paul On 5/16/19, 1:28 PM, "jdk8u-dev on behalf of Alvarez, David" <[email protected] on behalf of [email protected]> wrote: Hi, It has come to our attention that JDK-8048782 [1] can cause Pisces to perform wrong renderings. This patch was originally developed for OpenJDK9, but has now been backported to openjdk8u222, so it has become relevant again. After diving into the issue, it is my understanding that fix was created to solve potential RasterFormatException. That exception occurred by the fact that internally, PiscesCache always works with a bound box one pixel larger than specified, as it can see on its constructor [2]. That slightly larger bbox was exposed outside by the PiscesTileGenerator::getBbox method, and could lead to the RasterFormatException in some scenarios. JDK-8048782 addressed this by ensuring the bbox exposed outside did not contain the additional pixel. Calls to retrieve the bbox will now go to a PiscesCache::getBBox [3] method that removed the extra pixel. However, one thing that was not changed is the PiscesTileGenerator::nextTile method [4]. This method is still accessing the internal value. The new problem happens because now the AAShapePipe::renderTiles works with a different bbox that the PiscesTileGenerator::nextTile. This means that for certain sizes of the bbox (those multiple of 32, the tile size), AAShapePipe may start working with the next row while PiscesTileGenerator still considers we are on the current row. This issue generates patterns like the ones on the attached tile_misalignment.png image. This could be fixed by aligning the PiscesTileGenerator::nextTile method to use the same value for bboxX1 as the one that was exposed outside (removing the extra pixel). Something functionally equivalent to: public void nextTile() { if ((x += TILE_SIZE) >= cache.bboxX1 -1) { x = cache.bboxX0; y += TILE_SIZE; } } However, the part that I haven’t been able to understand is why PiscesCache works with that extra pixel. As far as I can tell, it has always been there, but I've never seen it documented. I assume there was a legitimate reason for that extra pixel to be there, but I don't know why or if it is still relevant. I would love if someone with more knowledge in this area were able to explain it. There seems to be three options here: - Revert JDK-804782, leaving the original RasterFormatException bug. - Address the misalignment by changing the PiscesTileGenerator::nextTile. - If no longer needed, remove the additional pixel in PiscesCache bbox (and reverting JDK-804782, that would no longer be needed) Thanks, David --- [1] https://bugs.openjdk.java.net/browse/JDK-8048782 [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/cecd70d27b27/src/share/classes/sun/java2d/pisces/PiscesCache.java#l62 [3] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d9da27985291/src/share/classes/sun/java2d/pisces/PiscesCache.java#l170 [4] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d9da27985291/src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java#l135 [5] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d9da27985291/src/share/classes/sun/java2d/pipe/AAShapePipe.java#l162
