Hi Denis,
Things got really busy for me over the past week so I wasn't able to
keep up with the discussion on this, but I will be looking more at it
next week. In the meantime it sounds like you are on the right track.
I wish I'd have investigated it to the level you are at so I could be of
more immediate help, but hopefully I'll get there when I review your
various changes...
...jim
On 9/7/2010 2:11 PM, Denis Lila wrote:
Hello Jim.
So, I finally have a webrev for serious consideration:
http://icedtea.classpath.org/~dlila/webrevs/noflatten/webrev/
There are still some printing statements I used for debugging, and
the whitespace is probably pretty bad (tell me if this poses a problem
when reading the code, and I'll clean it up), but I don't want to
waste time removing that stuff unless necessary, since this is
doubtlessly not the last version. I also included a Test.java
file that I found useful for testing and debugging. It has a main
method, and it allows pisces to run as a standalong project in
eclipse (as long as you set the JRE to be openjdk7 since it needs
to know about AATileGenerator and some other non public interfaces).
From testing it, the only problem I noticed is that it doesn't do
very well with tight loops. So, a path like
p.moveTo(0,0);p.curveTo(1000, 1000, 400, 500, 0, -150);
isn't stroked very well when using the rotating algorithm. When using
just the "make monotonic" algorithm it is ok (right now, it is set to
use the latter - you can change this by uncommenting Stroker.java:1011
and commenting out Stroker.java:1012). This leads me to believe that
we need to detect and perhaps subdivide at loops in addition to the
current subdivision locations. However, I have not yet looked too deeply
into why the problem arises and how to fix it. I welcome suggestions.
Thanks,
Denis.
I figured out what the problem is. The problem isn't really tight loops.
The problem is cusps in the offset curves. These happen when the line width
is equal to the radius of curvature of the curve being processed (although,
this may be just a necessary condition and not sufficient, but this doesn't
matter).
It seems like we have to split at values of t where the above condition
holds. However, I can't see a way to do this without resorting to Newton's
method
for finding the roots of RadiusOfCurvature(t) - lineWidth. It would be
really easy, however, if we had the arc length parametrization of the curve
in question, but this won't necessarily be a polynomial. A good way might be
to find a polynomial approximation to its inverse (this would make dashing
considerably
easier too).
Regards,
Denis.
----- "Denis Lila"<dl...@redhat.com> wrote:
----- "Jim Graham"<james.gra...@oracle.com> wrote:
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
