Hi Roman,
Ductus produces widened paths at the native level and since SSI is a
native piece of code, it implements native interfaces to receive the
widened path segments from Ductus directly without having to do upcalls.
The code feeding the original path is feeding it from the Java level,
but the widened path segments which are the output of the path widening
code get conveyed all at the native level.
With Pisces it is a Java library so it produces the widened paths at the
Java level and makes Java calls to a PathConsumer object to convey the
widened path. In the case of SSI, it now has to do downcalls per
segment to ingest the widened path into its native data structures.
...jim
Roman Kennke wrote:
Hi Jim,
Thanks for the exlanations. I think I will do like the X11Renderer and
use both rasterizers for the different cases, for maximum compatibility.
One more thing, you mentioned Ductus. How does the RenderingEngine
interface and the Pisces rasterizer fit into this picture? Is this yet
another rasterizer for yet another special case that is not covered by
the other two?
/Roman
All of that sounds correct. Also note that the ProcessPath stuff was
the stuff that Alexey wrote to combat the "unround ovals" problem, but
it rasterizes to pixels that aren't quite the theoretically correct
pixels. Technically the test should also take things like STROKE_PURE
into account as well.
The stroke state matters for filling because we want to use compatible
algorithms for filling and stroking and the ProcessPath stuff is
compatible with its own filling rasterization, but not compatible with
the rasterization of the ShapeSpanIterator stuff. Also, SSI has a
direct interface to the line widening code in Ductus (closed source),
but ProcessPath does not - so it defers to SSI for filling wide lines.
On the platforms tested on I believe that ProcessPath was faster than
SSI, but there could be some performance tweaks done to make SSI faster
as well (for one thing I believe it involves a lot of per-segment JNI
calls which we could reduce out).
We really need to design one rasterizer that can meet all of our needs
at some point, but we've never had the time to just focus on that goal...
...jim
Roman Kennke wrote:
Dear 2d-devs,
I want to implement a ShapeDrawPipe, and studying the X11Renderer
implementation I see that there seem to be two different approaches. One
is the (C-only) ProcessPath thingy (ProcessPath.h and ProcessPath.c),
the other is the ShapeSpanIterator, which is available both as Java and
as C API. In the X11Renderer we go into the ProcessPath in the
'sg2d.strokeState == sg2d.STROKE_THIN' case only, and otherwise the SSI
is used. The ProcessPath only uses drawLine(), drawPixel() and
drawScanline() operations, while the SSI produces rectangles for use in
a fillRect() operation. My questions:
- are the above observations correct? (Only want to be sure)
- what kind of a difference makes the strokeState for filling a shape? I
was under the impression that the stroke is only used when drawing
things. Or is that for the case when the fill() operation is actually
used as a 'backend' for another draw() operation?
- how does the performance of the ProcessPath compare to the SSI? Which
one should I use in my ShapeDrawPipe implementation? Or does it make
sense to use both, just like in the X11Renderer? And if so, then why?
Thanks for your answers in advance,
/Roman
