[Pixman] [PATCH] spans

[Taekyun Kim]

On 08/21/2011 04:54 AM, Chris Wilson wrote:
> Taekjun Kim made a good suggestion on how to eliminate the majority of
> the noise in the previous patch: simply handle opacity by first combining
> (mask IN opacity) in the general_composite_rect. The rest of the patch is
> then updating the internal API to propagate an opacity value from the new
> public interface.
>
> After a couple of weeks of work on the consumer of that public API, I've
> concluded that the minimal interface of adding a single opacity value that
> is equivalent to a mask is the simplest and yet complete enough for use by
> cairo to implement clipped shapes with an unbounded operator with no less
> efficiency than for bounded operations. (For the unbounded case, we create
> a second compositor using OUT_REVERSE with WHITE and select the compositor
> based on a bit in the span that indicates whether that span is
> inside/outside the shape.)
>

Because LERP is a ternary operator, we cannot simply replace "OP" by 
"LERP" in
equation "(src IN mask) OP dst". So we have to regard whole equation as OP
itself. For example,

Definition of PIXMAN_OP_OVER : (src IN mask) OVER dst
Definition of PIXMAN_OP_LERP : src LERP_mask dst

Now we have to add the opacity.
If we regard opacity as part of src, we can replace "src" with "src IN 
opacity" in
the above example equation. In the case of mask, we can replace "mask" with
"opacity IN mask".

To do single-pass polygon filling including clipping, as you mentioned,
"src LERP_(opacity IN mask) dst" would be good for operator SOURCE.

>  From which I can see that there is potential here, but it is dwarfed by the
> overheads in the current implementation. My next step is to change the
> rasterisers to spit out a RLE scanline in the form of (count, opacity[],
> runs[]) and pass the arrays of spans to pixman. I felt this would be a
> more invasive change and so avoided it... Suggestions very welcome.
>

Which part do you think consumes most of the time? Fast paths are not 
optimised
for width of 1. Per-pixel function calls are also significant overhead.

Maybe RLE encoding of spans gives more chance of optimization to pixman.
Internally, we can avoid per-pixel composite function calls by building 
a8 mask of
some portion of spans which contain non-opaque runs while remaining opaque
runs can avoid using a8 mask.

Some other options can be light-weighted pixel composite function. We know
that we would composite only a single pixel for a function call for 
non-opaque
runs, so we don't expect any loop handling or setting up overhead.

I have to think more about the efficient way of passing shape information to
pixman.

--
Best Regards,
Taekyun Kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20110822/06260b39/attachment.html>