OK, I see. You were doubting that the "thing that came after Pisces"
could be that much different considering that Pisces is rendering many
more sub-pixels.
Actually, embarrassingly I think it can. It just means the non-AA
renderer has some performance issues. One thing I can think of is that
the SpanShapeIterator uses a native method call per path segment and the
cost of the context switches into native and back for each path segment
dominate the performance of long paths. It was something I was meaning
to fix for a long time (when that code was first written native code was
so much faster than Java and the native transition was quick - since
then Hotspot came along, got a lot better, and the native transitions
got much, much slower).
So, yes, this isn't out of the question...
...jim
On 9/2/2010 3:40 PM, Denis Lila wrote:
Use which? The stroking code or the rendering code?
I believe that the way I set it up was that Pisces replaced both the
stroke widening/dashing code and the AA renderer - both were parts that
we relied on Ductus for. But, the widening code would talk to one of
our other existing rasterizers for non-AA. Look at
LoopPipe.draw(sg2d, s). It (eventually) calls RenderEngine.strokeTo()
directed at a SpanShapeIterator...
I think there's a misunderstanding. All I meant was that, even when AA is off,
we do use pisces for widening, but it doesn't do any rasterization.
----- "Jim Graham"<james.gra...@oracle.com> wrote:
...jim
On 9/2/2010 3:20 PM, Denis Lila wrote:
Do we use Pisces for non-AA? Pisces should clock in slower for AA
than
non-AA, but I think we use one of the other pipes (not Ductus) for
non-AA and maybe it just isn't as good as Pisces?
We definitely use it for non-AA.
I traced it.
Denis.
----- "Jim Graham"<james.gra...@oracle.com> wrote:
On 9/2/2010 2:43 PM, Denis Lila wrote:
Actually, I had a question about the test I wrote which takes 20
seconds. When
I turned antialiasing on, the test dropped from 20 seconds to
2.5.
This is very
puzzling, since antialiasing is a generalization of
non-antialiased
rendering
(a generalization where we pretend there are 64 times more pixels
than there
actually are). Of course, the paths followed after pisces for AA
and
non-AA are
completely different, but whatever came after pisces in the
non-AA
case would
have the same input as Renderer has in the AA case (input gotten
from Stroker).
Can you take a guess as to what was causing such a large
difference?
I think Pisces was integrated only as a Ductus replacement which
means
it was used only for AA, but check if I'm mistaken...
...jim
