J2SE 1.5.0 fillPolygon method

[John Dove]

Hi Java Folks,

Sorry to bother everyone, however, I am all out of ideas on a particular problem that I am having, and am hoping that someone can offer some advice. In short, my Java problem is as follows:

[1]
over the past year I have *successfully* implemented a "graphical geometry editor" using J2SE SDK 1.4.x. Again, everything worked fine under SDK 1.4.x, and life was good.

[2]
recently, however, I downloaded Sun's new J2SE SDK 1.5.0. I compiled my geometry editor successfully (without errors) against this new SDK 1.5.0, and then began using it. However, the following "fillPolygon" method of class Graphics is no longer working as it did before!

class: java.awt.Graphics
method: public void fillPolygon(Polygon p)

In short, any polygon that I render using this method is erroneously "offset" from where it **should** be rendered on my gui. In fact, here is an example of some code that exhibits this problem:

// I define a polygon using values x1,y1,x2,y2,
// which correctly defines a rectangle polygon
java.awt.Polygon squareMBRPoly = new java.awt.Polygon
(
new int [] {x1,x2,x2,x1},
new int [] {y1,y1,y2,y2},
4
);

// I set the graphics object color to an arbitrary value, in this case "orange"
g.setColor(Color.orange);

// I render the outline of the polygon via the "drawPolygon" method,
// which is **successful**, thus I know that my polygon definition
// is valid
g.drawPolygon(squareMBRPoly);

// next, I render a "filled" version of this **same**
// polygon object, however, it is INCORRECTLY offset
// when drawn to the gui. The polygon's shape is correct,
// it is simply been offset erroneously!!!
g.fillPolygon(squareMBRPoly);


[3]
Again, my same "geometry editor" source code, when compiled under J2SE SDK 1.4.x, runs correctly. I only get this problem when I switch to compiling and running my geometry editor under SDK 1.5.0. Offhand, I would say that there is a bug somewhere in the 1.5.0. SDK. This sounds ridiculous I know, however, I cannot think of any other reason for this runtime rendering behavior. FYI: I am SCJP/SCJD certified and have a BS degree in computer science & mathematics (just so you know that I am not a complete idiot. :-)


Any thoughts?


Best Regads,
John Dove
[e-mail]
[e-mail]
http://home.nycap.rr.com/jdove

[Ernest Friedman-Hill]

Here is an entry in Sun's Java Bug Database pertaining to fillPolygon() in 1.5. It's an open bug. They say it's "possibly an X11 problem." So what platform are you running on? On Linux or Solaris, or on Windows?

[John Dove]

Hi Ernest,

Thank you very much for the reply. I read the bug report that you had cited (i.e. Bug ID: 4937390), such that my comments are as follows:
Comments:

[1]
In regard to your question, the platform I am using for the development and testing of my geometry editor is as follows:

cpu type: intel pentium
cpu speed: 1.9 GHz
memory: 512MB
operating system: WindowsXP, HomeEdition, version 2002 (service pack 2)


[2]
In regard to the bug you cited (i.e. Bug ID: 4937390), it claimed that the polygon was rendered incorrectly (i.e. meaning its physical shape was not correct). In my case, and under SDK 1.5.0 only, my polygon's physical shape is rendered correctly, however, its position (i.e. the location on the screen where is is drawn) is erroneously "offset" from where it should be. Overall, my problem is different than bug 4937390, however, they might be linked. <shrug>

[3]
In the next day or two, I will write a very small sample application that attempts to demonstrate this behavior (i.e. in order to remove the concerned functionality from out of the editor that I have written, which is quite large (~4.0MB of source). I will post the results of my testing back here to the Java Ranch. In general, if I can consistently reproduce this behavior in a small isolate Java program, I will likely submit it to Sun as a bug

In any case, it is interesting to learn that there are confirmed problems in SDK 1.5.0 regarding the fillPolygon method. Ernest, if you or anyone else reading this forum thread happen to learn more about this problem, could you please post back? :-) Thanks.

Regards,
John Dove
[e-mail]
[e-mail]
http://home.nycap.rr.com/jdove

P.S. Ernest, I followed the link on your posting, which lead to a bit about the Jess book you wrote. Very cool. Btw, I am in the process of writing a Java video game programming book, such that the editor I am having a problem with (above) is a tool that I will ship with the book (if/when) the book ever actually gets finished. There is never enough time in the day.

[Layne Lund]

Feel free to email me the source code of your "simplified" example. I will be glad to take a look at it and see if I can also reproduce the problem.

BTW, have you tried using the 1.5 compiler to generate 1.4 bytecode? Does this also produce the incorrect "offset" polygon?

Layne

p.s. You may also be interested in using UBB CODE tags when you post code here in the future. They will preserve the formatting in your code (assuming that you have good formatting habits after getting your BS ) and make it much easier for us to read.
[ July 20, 2005: Message edited by: Layne Lund ]

[John Dove]

Hi Layne,

>>> Feel free to email me the source code of your "simplified"
>>> example. I will be glad to take a look at it and see if
>>> I can also reproduce the problem.

Thank you for offering to help out! :-) I have not had a chance to create my trivial example for debugging purposes (wife, job and after work stuff keep me running in circles weekly). In the worst case scenario, I will have to "put off" doing this until this weekend. (Maybe I can sneak in a few lines of code while at work when my moss isn't around. ;-)



>>> BTW, have you tried using the 1.5 compiler to generate
>>> 1.4 bytecode? Does this also produce the incorrect
>>> "offset" polygon?

Not yet. I can look into this though.




>>> p.s. You may also be interested in using UBB CODE tags
>>> when you post code here in the future. They will
>>> preserve the formatting in your code (assuming that you
>>> have good formatting habits after getting your BS ) and
>>> make it much easier for us to read.

hehe Will do :-) What UBB codes do you usually employ (e.g. just bold-type the comments?)

[Ernest Friedman-Hill]

Originally posted by John Dove:
What UBB codes do you usually employ (e.g. just bold-type the comments?)

Just use [ CODE][/CODE] tags around your formatted code, and UBB will preserve the indentation -- that's all.

[John Dove]

Hi Guys,

I was successfully able to abstract the "polygon problem" I am seeing out of my larger program, and into the below smaller one (see below). I tried using the

tags, so hopefully it will look ok. From what I am seeing, this "problem" is one of the following possibilities:

1. a bug in the J2SE 1.5.x SDK.
2. or a usability problem in the J2SE 1.5.x SDK. In other words its a WAD (works as designed) but it is NOT documented plainly enough for developers like myself to catch it.

Please let me know what you think. Thanks again for your help. If there is anything else that you need please let me know. I can send you the actually source code file via email if you like (i.e. I will need your addresses), as well as screen shots of what I am seeing at runtime under both 1.4.x and 1.5.0 SDK versions.

To that end, here is my little code piece, all sublime:

Thanks,
John

package possible.fillPolygon.bug;
 
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
// declare imports
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
 
// j2se sdk imports (applicable to both 1.4.x and 1.5.x sdk versions)
import javax.swing.*;
import java.awt.*;
import java.awt.image.*;
        
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
// top-level public class
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
/**
 * this small SWING application program demonstrates a possible bug between
 * the 1.4.x and 1.5.0 version of the J2SE SDK api.  Specifically, this program
 * functions as follows:
 *
 * 1. it is a SWING application.
 * 2. it creates a JComponent subclass and overrides its "paint" method in
 *    order to "hardcode" the drawing of a polygon.
 * 3. the polygon image is drawn twice, such that the first drawing is done
 *    via a "fillPolygon" method call, and the second drawing is done via a
 *    "drawPolygon" method call.  The former draws the polygon and fills its body
 *    with a color; the latter simply draws the outline of the polygon.
 * 4. the "drawPolygon" method functions correctly under both SDK 1.4.x and 1.5.x.
 * 5. the "fillPolygon" method functions correctly under SDK 1.4.x, but NOT
 *    under SDK 1.5.x.  Specifically, in terms of SDK 1.5.x, the fillPolygon method
 *    renders the filled polygon at an offset from where it should be.
 * 
 * 
 * To see this discrepancy in behavior, simply compile this small source code
 * file under SDK 1.4.x xor SDK 1.5.x and run it.
 *
 * IMPORTANT: this behavior only occurs when the paint method draws the polygon
 * into a BufferedImage object's graphics object, such that afterward, the
 * BufferedImage object is then drawn into the Graphics object of the paint 
 * method itself.  If a bufferImage object is NOT used, thereby drawing the
 * polygon directly into the GRaphics object of the paint method, then the behavior
 * works correctly under both 1.4.x and 1.5.0.  In general, it appears that this
 * problem is related to the combined functioning of the BufferedImage class
 * and its "fillPolygon" method.
 *
 * @author John Dove scjp/scjd July 2005
 */
public class App extends JFrame
{
  //////////////////////////////////////////////////////////////////////////////
  //////////////////////////////////////////////////////////////////////////////
  // inner class
  //////////////////////////////////////////////////////////////////////////////
  //////////////////////////////////////////////////////////////////////////////
  
  /**
   * inner JComponent subclass, which has hardcoded logic for drawing the 
   * polygon.
   */
  class ImageCanvas extends JComponent
  {
    public void paint(Graphics g)
    {
      // create a bufferedImage object, into which we will draw our polygon
      // images (i.e. the outline of the polygon via the "drawPolygon" method,
      // and the filled polygon via the "fillPolygon" method, the latter of
      // which seems to have the problem)
      BufferedImage bi = new BufferedImage
      (
        this.getWidth(),
        this.getHeight(),
        BufferedImage.TYPE_INT_RGB
      );
      Graphics big = bi.getGraphics();
 
      // offset value that is added to the coordinates of the polygon,
      // which moves it "out of visible rendering range" in Java user space,
      // which has an upper left device coordinate of (0,0) and extends to
      // the extents of this JComponent subclass when "realized" on the screen.
      // (Just look at the remainder of this code, it is very trivial - you will
      // understand.)
      int offsetX = 1073741793;
      int offsetY = 1073741793;
      
      // define the vertex offsets of the polygon in terms of pixels. In this
      // case our polygon will look like a small triangle
      int [] polygonVertexOffsetsX = new int[] {0, 30, 0};
      int [] polygonVertexOffsetsY = new int[] {0, 0, 30};
      
      // now, add the above "offset" x/y values to the vertex arrays
      System.out.println("-----------------------------------------------------");
      for(int i=0; i<3; i++)
      {
        polygonVertexOffsetsX[i] += offsetX;
        polygonVertexOffsetsY[i] += offsetY;
        System.out.println("polygon vertex ["+i+"]: ("+polygonVertexOffsetsX[i]+","+polygonVertexOffsetsY[i]+")");
      }
      System.out.println("-----------------------------------------------------");
      
      // take the graphics object of the BUFFERED IMAGE, and set its "translation"
      // value such that it "translates" any rendered polygon's back into 
      // our Java user space "view."  Technically, the values of this translate
      // setting will be "added" to any pixels that are rendered, thereby 
      // affecting the final and resultant pixel location. In other words, we
      // will render our polygon and bring it into view.
      int translateX = -1073741664;
      int translateY = -1073741664;
      big.translate(translateX,translateY);
      
      // define a polygon object using our vertices
      java.awt.Polygon polygon = new java.awt.Polygon
      (
        polygonVertexOffsetsX,
        polygonVertexOffsetsY,
        polygonVertexOffsetsX.length
      );
 
      // draw a filled version of this polygon
      big.setColor(Color.yellow);
      big.fillPolygon(polygon);
      
      // draw the polygon outline
      big.setColor(Color.blue);
      big.drawPolygon(polygon);
      
      // NOTE: these two polygon renderings should be drawn at the same location,
      // however under SDK 1.5.x, the "fillPolygon" method draws the filled
      // polygon at an offset from where it should be.
      
      // draw the BUFFERED IMAGE into this method's Graphics object
      g.drawImage(bi,0,0,this);
      
      // NOTE: if a BUFFERED IMAGE is NOT used, and the polygons are drawn 
      // directly into the Graphics object of this method itself, then
      // both SDK 1.4.x and 1.5.0 work correctly.  Thus, this appears to be
      // a problem with the rendering of poylgons via the "fillPolygon" method
      // specifically within BufferedImage objects.
    }
  }
 
  //////////////////////////////////////////////////////////////////////////////
  //////////////////////////////////////////////////////////////////////////////
  // methods
  //////////////////////////////////////////////////////////////////////////////
  //////////////////////////////////////////////////////////////////////////////
  
  public App() 
  {
    ImageCanvas ic = new ImageCanvas();
    getContentPane().add(ic);
    this.setSize(640,480);
    this.setVisible(true);
  }
  
  public static void main(String[] args) 
  {
    new App();
  }
}

[Ernest Friedman-Hill]

Well, I can confirm your observations; same thing happens for me (1.4.2_08 vs 1.5.0_02, both on Linux.)

I note (as I'm sure you did) that the size of the effect is related to the size of the offsets; if the offsets are two orders of magnitude smaller, the effect is not apparent. Sounds, therefore, like floating-point roundoff error.

[John Dove]

Hi Ernest,

Thank you for the confirmation. At this point what do you suggest that I do? I have never submitted a "bug" to Sun. Since we have a reproducible test case here, what are the exact steps for notifying Sun about it?

Regards,
John Dove
[e-mail]
http://home.nycap.rr.com/jdove

[Ernest Friedman-Hill]

It's pretty straightforward, I think: go to http://bugs.sun.com/services/bugreport/index.jsp to get started.

[John Dove]

Thanks, I sucessfully logged it as a bug. Again, thank you for your "second pair of eyes" on this problem. I appreciate it.

Going back to SDK 1.4.x now... :-)

FYI, I got the following confirmation from Sun on the bug I posted:

************************************************
Your report has been assigned an internal review ID of: 494063

This review ID is NOT visible on on Sun Developer Network (SDN).

We greatly appreciate your interest in improving the quality
of Java(tm) Technology from Sun Microsystems.

Please be aware that the large volume of reports we receive
sometimes prevents us from responding individually to each
message.