[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Question regarding filling shapes
From:       Jim.A.Graham () Sun ! COM (Jim Graham)
Date:       2008-10-28 21:49:55
Message-ID: 0K9G00GA0XZ7U920 () fe-sfbay-09 ! sun ! com
[Download RAW message or body]

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
>>>


[prev in list] [next in list] [prev in thread] [next in thread]