[OpenJDK 2D-Dev] More incompatibilities

[Jennifer Godinez]

Thanks!  I will be looking into these patches and have them reviewed.

Jennifer

Roman Kennke wrote:
> 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