Hi Denis,
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.
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
