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.ken...@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 > > >