Hi Roman,
Apologies for not replying to you sooner. As far as I know, Jim made comments on the fix. Have you
looked into these? Whether or not you have, please go ahead and enter the patch into Bugzilla so
we can better keep track on them.
Jennifer
Roman Kennke wrote:
Hi,
Is it possible to get an update on these patches or did the whole Java2D
team just disappear? ;-) Should I enter the patches into Bugzilla or
should I simply wait? What's happening with them now?
/Roman
so what happens now with this patch and the others? Should I enter them
into Bugzilla, so they don't get lost? Are they already in the process
of beeing integrated?
/Roman
Am Dienstag, den 03.03.2009, 16:17 +0100 schrieb Roman Kennke:
Hi there,
4. StrokeShapeTest: createStrokedShape() behaves differently.
It turns out that there is an arithmetic overflow here. The pisces
stroker does a stupid thing here. First it initializes the
scaledLineWidth like this:
this.scaledLineWidth2 = ((long)transform.m00*lineWidth2);
which is infact wrong, because in fixed point arithmetics you need to
apply >> 16, because the decimal moves.
However, in another place it uses this factor like this:
dx = (int)( (ly*scaledLineWidth2)/ilen >> 16);
dy = (int)(-(lx*scaledLineWidth2)/ilen >> 16);
which makes it ok in the end. The only problem is, that we start with an
incredibly large number, then multiply another incredibly large number
and _after_ that (when the overflow already occured) do the >> 16. The
patch moves the >> 16 to the initialization of scaledLineWidth, which
makes it clearer, more correct and even a tad faster, because we do the
second calculation at least 2x.
Of course, the real fix here would be to turn the whole implementation
into floating point. This particular testcase is fixed by this patch,
and the 'range of correct behaviour' is much large now, but if you deal
with very large numbers in your shapes, then you will get trouble again.
/Roman
