[OpenJDK 2D-Dev] More incompatibilities

[Hiroshi Yamauchi]

FYI, the join miter patch seems to have gone in:

http://hg.openjdk.java.net/jdk7/2d/jdk/rev/9318628e8eee

but probably the other patches didn't. I also would like to see these
patches go into openjdk soon.

Thanks,
Hiroshi

On Thu, Mar 26, 2009 at 7:16 AM, Roman Kennke <roman.kennke at aicas.com> 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
>
>
>