Hello Jim.
So, I've now implemented both suggestions you had for implementing
stroke control: an intermediate normalizing path iterator, and
doing flattening in pisces at the lowest level. Respectively,
the webrevs are:
http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/
http://icedtea.classpath.org/~dlila/webrevs/fpWithSCandPiscesFlattening/webrev/
Again, these include the floating point conversion changes, but all of the
changes relevant to this e-mail are in PiscesRenderingEngine.java.
As for performance, the version with low level flattening is faster, but this
is only noticeable when pisces is run on it's own i.e. not actually drawing
anything (by the way, I've included a commented out main method in the second
webrev. This allowed me to run pisces on it's own which was useful for debugging
and performance testing).
However, when drawing stuff, whatever happens after pisces takes up so much
time that it's hard to tell the difference.
Nevertheless, it might be worth to keep the somewhat ugly, low level version.
It might be useful for antialiasing if Stroker moves to outputting curves
instead
of just lines (because AA still needs to flatten, unless someone comes up with
an
algorithm to do it without flattening, but I can't think of anything).
I'm sorry to ask you specifically for all these reviews - you've already spent
a lot of time looking at my work, but no one else has replied to any of my
pisces
inquiries (except Clemens Eisserer, on this issue). Anyway, I would appreciate
it
if you, or anyone, could take a look at one or both of the above webrevs.
Or maybe we could leave it for when the floating point conversion has been
pushed.
Then the webrevs would have a lot less clutter.
Thanks,
Denis.
- "Denis Lila" wrote:
> Hi Jim.
>
> I implemented STROKE_CONTROL today. I used the intermediate
> NormalizingPathIterator, instead of implementing flattening in
> pisces, because I wanted to get something working asap, and this
> would be the easiest way.
>
> The webrev is
> http://icedtea.classpath.org/~dlila/webrevs/fpWithStrokeControl/webrev/
>
> I guess I'm not asking that you take a look at it, because it's
> probably
> not the way we're going to end up doing things, but I wrote it, so
> I'm sending the link just in case anyone wants to see it.
>
> The webrev is big because it includes the floating point conversion,
> but all the
> STROKE_CONTROL changes are in PiscesRenderingEngine.java.
>
> Thanks,
> Denis.
>
> - "Jim Graham" wrote:
>
> > Hi Denis,
> >
> > It would be ill-advised to normalize the coordinates after
> flattening.
> >
> > The quality would be really bad.
> >
> > Perhaps this is a good reason to start looking at updating Pisces to
> > take curves and flatten at the lowest level?
> >
> > Or, I suppose we could get a non-flattened iterator from the source
> > path, send it through a "normalizing" filter, and then through a
> > flattening filter (the way many of the existing objects do
> flattening
> > is
> > to just get their regular iterator and run it through an instance of
> > FlatteningPathIterator so we could do this manually with an
> > intervening
> > "NormalizingPathIterator" if normalization is needed)...
> >
> > ...jim
> >
> > Denis Lila wrote:
> > > Hello Jim.
> > >
> > > Thanks for that. I'll get to work on implementing it.
> > >
> > > One thing though, about normalizing the control points of bezier
> > > curves: pisces never gets any bezier curves as input. It only gets
> > > lines that are the product of flattening bezier curves.
> > >
> > > Pisces receives its input from flattening path iterators which get
> > it
> > > from other path iterators. Of course we can't require these to
> send
> > out
> > > normalized points. In order to normalize the control points we
> need
> > to
> > > be able to look at the bezier curves in Pisces, so we can't just
> > take
> > > all the input from the flattener. However, pisces can't handle
> > curves
> > > (yet, hopefully), so after the normalization, they must be
> > flattened, and
> > > this is the problem. I think it's a pretty good idea to do this by
> > > storing the input form the iterator into pisces (after
> > normalization),
> > > creating a nameless path iterator that just iterates through all
> > that,
> > > and using this iterator to create a flattening iterator, which
> then
> > > is used as before.
> > >
> > > Does anyone have any other ideas?
> > >
> > > Thank you,
> > > Denis.
> > >
> > >
> > > - "Jim Graham" wrote:
> > >
> > >> For AA this is exactly what we do (round to nearest pixel centers
> > for
> > >>
> > >> strokes). Note that this is done prior to any line widening code
> > is
> > >> executed.
> > >>
> > >> For non-AA we normalize coordinates to, I believe the (0.25,
> 0.25)
> >
> > >> sub-pixel location. This is so that the transitions between
> > widening
> > >> of
> > >> lines occurs evenly (particularly for horizontal and vertical
> wide
