[OpenJDK 2D-Dev] More incompatibilities

Roman Kennke roman.kennke at aicas.com
Tue Mar 3 10:09:51 UTC 2009

Hi there,

> I believe that the minX and maxX parameters to that function are 
> relative to the origin of the raster coordinates which means you would 
> add each of them to the raster's origin (rasterMinX) to get an absolute 
> min/maxX.  So they look correct as written.
> If this change fixes the problem, then it is a side effect of moving the 
> right edge of the "startRow" call out to the right some more.  That 
> could indicate that perhaps maxX was not calculated correctly in the 
> first place and so expanding it out "covers up" the problem.

I had a look at that code. It seems like minX and maxX are calculated
correctly. However, in emitRow, we calculate x0 and x1 from that, and
then call the cache.startRow() with that to start a new row in the RLE
cache. It seems like the cache (or the rendering code that reads the
cache) interprets x1 to be the first pixel right of the bounding box,
while the emitRow() function needs that pixel _inside_ the bounding box
(it does while (srcIdx <= maxX) { .. } ). The following patch fixes the
problem for me:

diff --git a/src/share/classes/sun/java2d/pisces/Renderer.java
--- a/src/share/classes/sun/java2d/pisces/Renderer.java
+++ b/src/share/classes/sun/java2d/pisces/Renderer.java
@@ -634,7 +634,7 @@
                 int x0 = minX + (rasterMinX >>
                 int x1 = maxX + (rasterMinX >>
-                cache.startRow(y, x0, x1);
+                cache.startRow(y, x0, x1 + 1);
                 int srcIdx = minX;
                 // Perform run-length encoding


Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt

More information about the 2d-dev mailing list