[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Various fixes to pisces stroke widening code
From:       james.graham () oracle ! com (Jim Graham)
Date:       2010-08-07 1:40:30
Message-ID: 4C5CB98E.1020304 () oracle ! com
[Download RAW message or body]

To the end of getting rid of "flips" - all they are used for is to 
resize the crossings array, right?  This is not a huge array that costs 
a lot to resize - why not simply use a default array of, say, 30 
elements and then resize it if we ever have more crossings than that? 
Only very complicated paths would have more than 30 crossings to track. 
  The check for array length is only needed once per scanline since we 
know how many active edges are on each scan line (hi-lo) and you can 
only have 1 crossing per active edge so with one test per scanline we 
can keep the crossings array within range...

			...jim

Jim Graham wrote:
> Hi Denis,
> 
> Well, I guess it's a good thing that Java2Demo had a path like that in 
> it - not a very common case, so it's good we found it!
> 
> The fix looks fine.  It still seems like there is way more logic there 
> than is needed - hopefully if we can get rid of flips at some point, 
> much of it will go away.
> 
> Fixes look good to go to me...
> 
>             ...jim
> 
> On 8/5/2010 3:58 PM, Denis Lila wrote:
>> Hi Jim.
>>
>> I didn't know about Java2Demo. If I did I would have run it sooner.
>> But I ran it a few hours ago, and everything looked fine (surprisingly
>> high fps too) until I got to the append test.
>>
>> Apparently I introduced a bug when solving the "2 consecutive moveTos 
>> bug".
>> Basically, when there's a close() after a horizontal lineTo(), the lineTo
>> in close() won't be executed because it's inside the if 
>> (firstOrientation != 0)
>> test. So instead of going back to the starting point, close will stay 
>> where
>> it is, which will draw a triangle above the rectangle.
>>
>> I fixed this by introducing a variable that keeps track of the last 
>> method
>> called (lineTo, moveTo, or close), and instead of checking for 
>> firstOrientation != 0
>> in close(), I check for (last == LINE_TO).
>>
>> webrev (hopefully final):
>> http://icedtea.classpath.org/~dlila/webrevs/fpBetterAAv2/webrev/
>>
>> I'm sorry about this. I wish I had known about Java2Demo sooner.
>>
>> Thanks,
>> Denis.
>>
>> ----- "Jim Graham"<james.graham at oracle.com>  wrote:
>>
>>> Hi Denis,
>>>
>>> That's great!  I just did a last minute double-check of your last
>>> (final) webrevs to be sure.
>>>
>>> Have you tested Java2Demo with these changes?  I'd also run any
>>> regression tests you can find with the changes.  If there are no
>>> problems there, then you are good to go to push it...
>>>
>>>             ...jim
>>>
>>> On 8/5/2010 8:08 AM, Denis Lila wrote:
>>>> Hello.
>>>>
>>>>> Are you a registered OpenJDK developer?
>>>> I am now.
>>>> Can I go ahead and push it?
>>>>
>>>> Regards,
>>>> Denis.

[prev in list] [next in list] [prev in thread] [next in thread]