[OpenJDK 2D-Dev] More incompatibilities

[Roman Kennke]

Hi Jennifer,

> Apologies for not replying to you sooner.

No problem.

>   As far as I know, Jim made comments on the fix.  Have you 
>   looked into these?

Jim commented on the fix for bug #3 that I haven't looked at yet. I will
do so tomorrow.

>   Whether or not you have, please go ahead and enter the patch into Bugzilla so 
> we can better keep track on them.

I entered the 3 patches for the other 3 problems into bugzilla, and will
do the same for the other as soon as I implemented Jim's suggestions.

The bugs are 100030, 100031 and 100032 in bugzilla.

Thanks, Roman

> 
> 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
-- 
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