[OpenJDK 2D-Dev] Question regarding filling shapes

[Roman Kennke]

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
> > 
-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20081028/e7d770f2/signature.asc>