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
