Hi Rhett,

In 1.2 we tried to deal with stroke/fill pixelization and alignment
issues by specifying a user-space offest for strokes so that the
typical behavior on a screen using standard bresenham algorithms for
drawing lines and polygon borders would be closely approximated in a
theoretical world of floating point coordinates and transforms.
Unfortunately the concept of a user-space offset was untenable for many
of the reasons that you seem to have stumbled upon with the Apple
implementation.  I'm pretty sure that their behavior is an
approximation of what we had been doing for quite a while in some parts
of our implementation (but not all).  You may indeed have witnessed
this same behavior in one of our older implementations if you had
written your test case just the right way to trigger it.

I believe we abandoned this concept in 1.3 (the release where we
introduced the "STROKE_CONTROL" hints).  Our implementation should be
pretty consistent in that release and following, but Apple may not have
noticed the change and updated their implementation to match.

You might also try downloading their preview of 1.4 from the Apple site:

       http://developer.apple.com/java/

and see if the problem is still reproducible.  If it is, you might want
to submit this bug report to them so that they can update from the old
user-space offset model of things to the new "STROKE_CONTROL" model...

                               ...jim

--On Monday, November 25, 2002 12:52 PM -0600 Rhett Sutphin
<[EMAIL PROTECTED]> wrote:

Hi,

I've run into what seems to be a pretty significant bug with Java2D on
OS X.  I couldn't find any mention of it in the archives of this list,
so I'm curious about whether anyone else has ever run across it and
what workarounds you might have used.

This is not the only oddity I've experienced with Java2D on OS X, but
it is the first one I've needed/been able to pin down with a test
case.

The problem is this:  whenever the Graphics2D object used to paint a
JPanel (or, presumably, any JComponent) has both a non-identity scale
factor and a non-default BasicStroke applied to it, any shapes drawn
to it willbe offset by some amount.  The amount and direction of the
offset appears to be proportional to the scale factor(s).  It doesn't
take a very large scale factor to displace the shape by a lot.  On the
other hand, the attributes of the stroke do not seem to affect the
degree of displacement.

(By "non-default BasicStroke", I mean any BasicStroke that's not 1.0f
wide with the JDK-default CAP and JOIN styles.  It doesn't have to be
the original Stroke object that "came with" the Graphics2D object,
just an equivalently-constructed one.)

If you remove either the scale or the BasicStroke, the other is
applied to the shape with no problem.  Some other variables I've
tried:

* If the source of the Graphics2D is a BufferedImage (instead of a
JPanel), the problem doesn't occur.
* The value of the rendering hint KEY_STROKE_CONTROL has no effect.

I've attached a small test case that demonstrates the problem with
different scale factors.  I've tested it on OS X 10.2.2 using the
included JDK (1.3.1) where the problem occurs, and on Windows 2000
with JDK 1.3.1_04 where the problem does not occur.  (Not that it
matters, but the test app is compiled under OS X.)

I have worked around this problem by doing something like this:

     public void transformAndDrawTo(Graphics2D g2) {
         AffineTransform origTx = g2.getTransform();
         g2.setTransform(new AffineTransform());
         g2.draw(origTx.createTransformedShape(shape));
         g2.setTransform(origTx);
     }

Where "shape" is whatever Shape I want to draw.  Of course, this has
performance penalties (though not as much as I expected) and it ends
up drawing something which does not exactly match what the "natural"
method would have [this could be alleviated (but not fixed) by scaling
the BasicStroke itself].  It works okay, but I wish I didn't have to
do it.

Anyone have any insights?  Is there something I'm overlooking?

I understand that this is almost certainly Apple's problem, since they
maintain their own JDK for OS X.  So if the answers to those two
questions is "no," the next question is: what is the best way to
report JDK bugs to Apple?

Thanks for reading that whole thing,
Rhett Sutphin
=====================================================
| Rhett Sutphin
| Research Assistant (Software)
| Coordinated Laboratory for Computational Genomics
|   and the Center for Macular Degeneration
| University of Iowa - Iowa City, IA 52242 - USA
| 4111 MEBRF - email: [EMAIL PROTECTED]
=====================================================
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to