[OpenJDK 2D-Dev] More incompatibilities

[Jennifer Godinez]

Hi Hiroshi,

All the patches are in
https://bugs.openjdk.java.net/

The IDs are: 100030, 100031, 100032, 100035

Jennifer

Hiroshi Yamauchi wrote:
> Hi Jennifer,
> 
> Do you mind pasting the URL links to the patches in this thread? I'd
> like to backport them into our openjdk6 tree.
> 
> Thanks,
> Hiroshi
> 
> On Mon, Apr 6, 2009 at 12:23 PM, Jennifer Godinez
> <Jennifer.Godinez at sun.com> wrote:
>> Hi Roman,
>>
>> Thanks for submitting the patches.  I got all 4 now.  I'm working on it but
>> Jim needs to review the changes.  He's on vacation now so don't expect to
>> get anything very soon until he gets back.  I will keep you updated.
>>
>> 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