[OpenJDK 2D-Dev] More incompatibilities

[Jennifer Godinez]

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