Hi Jim.

> The problem is that pruning complicates the inner loop that advances
> the scanline and you can't tell without scanning every segment in play 
> whether you need to do it in its own loop.  Thus, for one of my test 
> cases it was really expensive without some up front record of whether
> or not the pruning was needed.

Ah, I see. I misunderstood this yesterday. I read the line as
...[firstCrossing - boundsMinY] |= 1 instead of ...[lastCrossing-boundsMinY] |= 
1.
My bad.

Regards,
Denis.

----- "Jim Graham" <james.gra...@oracle.com> wrote:

> Hi Denis,
> 
> Also, I keep a count so I can amortize the "widenArray" call.  Before
> I 
> was calling "widen(..., 1)" inside the loop that drew new edges in
> from 
> the bucket.  I could also have added an additional loop to count the
> new 
> edges, but that would have been expensive as well...
> 
>                       ...jim
> 
> On 11/8/2010 3:23 PM, Denis Lila wrote:
> > Hi Jim.
> >
> > I like the new Renderer, but I have a question about
> edgeBucketCount.
> >
> > As far as I can see it is only used so that we can tell whether
> > any given bucket contains only edges that go all the way to the
> last
> > (or beyond) scanline. Is this really common enough that we gain by
> > treating it as a special case? Would it not be better to assume
> that
> > every bucket needs pruning and save some memory (and possibly
> resulting
> > in better cache performance)?
> >
> > Thanks,
> > Denis.
> >
> > ----- "Jim Graham"<james.gra...@oracle.com>  wrote:
> >
> >> It's still a work in progress, but I've cleaned up a lot of logic
> and
> >>
> >> made it faster in a number of ways.  Note that I've abstracted out
> the
> >>
> >> cache stuff and created an "AlphaConsumer" interface which may
> evolve
> >>
> >> over time.
> >>
> >> In FX we actually consume alphas in larger chunks than the code in
> JDK
> >>
> >> which was driven by Ductus's 32x32 mandate, so I would have had to
> >> make
> >> completely incompatible changes to emitRow - so I moved it behind
> an
> >> interface.  For the JDK code, if you want to integrate this
> version, I
> >>
> >> would have the cache implement the new interface and move your
> version
> >>
> >> of emitRow into the Cache object.  I'd send you the new code for
> my
> >> AlphaConsumer, but it is incompatible with what you need to cache
> so
> >> it
> >> won't help you.
> >>
> >> You'll also need a bit of un-translation cleanup as we have mirrors
> of
> >>
> >> all of java.awt.geom with special new APIs that FX needs.
> >>
> >>                    ...jim
> >>
> >> On 11/8/2010 6:40 AM, Denis Lila wrote:
> >>> Hi Jim.
> >>>
> >>>> Also, I've gotten another 20% improvement out of the design with
> a
> >> few
> >>>> more tweaks.  (Though I measured the 20% in the stripped down
> >> version
> >>>> that I'm prototyping with FX so I'm not sure how much of that
> 20%
> >>>> would show up through the layers of the 2D code.  Overall, I've
> >> about
> >>>> doubled the frame rates of the prototype since your first drop
> that
> >> you
> >>>> checked in to the OpenJDK repository.)
> >>>
> >>> Can I see your new version?
> >>
> >> Attached.
> >>
> >>>> How about looking more at the stroking end of the process and
> I'll
> >> dig
> >>>> a little more into optimal rasterization code.  I have a lot of
> >>>> experience with optimizing rasterizer code (and JNI if it comes
> to
> >> that), but
> >>>> very little with the curve manipulations involved in stroking
> (math
> >> is so
> >>>> *hard* at my age ;-)...
> >>>
> >>> Sounds good. Have you implemented your idea of processing one
> pixel
> >> row at a
> >>> time, as opposed to processing subpixel rows? If not, I could do
> >> that.
> >>
> >> Not yet.  Right now I've gotten a lot of mileage out of a few
> tweaks
> >> of
> >> the bookkeeping of the sample-row-at-a-time version.  I'm still
> >> mulling
> >> over exactly how to make that go faster.
> >>
> >>                            ...jim

Reply via email to