[Pixman] [RFC] A spans interface for pixman

[Soeren Sandmann]

Taekyun Kim <podain77 at gmail.com> writes:

> I think pixman polygon image is a vector representation of an alpha
> mask. I have several questions to søren about polygon image.

For reference, the current polygon code is here:

        http://cgit.freedesktop.org/~sandmann/pixman/log/?h=polygon

though it's not ready to go in yet.

The polygon image is similar to the gradients in that they are computed
images that can only be used as sources.

> 1. If polygon image is used as a src, is it treated as just a8 image?

Yes; to be a bit more precise, with the current code, the alpha channel
is a sampled version of the polygon and the rgb channels are 0. Ie., the
pixels are black with varying levels of opacity.

An interesting alternative possibility would be to consider the RGB
channels duplicates of the alpha channel, which would make the pixels
shades of white instead. In the typical usecase:

        ((solid color) IN (polygon)) OVER destination

nothing would change, but it would be useful if we add a set of LERP
operators that would do:

        (src OP dest) LERP_m dest

where LERP_m (a,b) is defined to do 

         m * a + (1 - m) * b

because with a white mask, this operator could be applied across all
four channels, which would then make operations with component-alpha
similar to regular alpha, so we wouldn't need the component_alpha
property anymore.

> 2. If polygon image is used as a dest, is it converted to bits image?

Just like gradients, it would be illegal to use a polygon as a
destination.

> 3. What if pixman_image_get_data() is called on polygon image?

You would get NULL.

> 4. How can I fill intersection of two (or more) polygon images?

With the current code, you'd have to either compute the intersection
polygon yourself, or SRC (polygon1 IN polygon2) to an image, then use
that image with the usual (solid IN mask) dest.

It could be interesting to add support for polygon operators:

        pixman_image_create_polygon_intersection (polygon1, polygon2)
        pixman_image_create_polygon_union (polygon1, polygon2);
        ...

These would return a new polygon image that would contain pointers to
the other two. When the new image is used for rendering, the
intersection/union/etc would be computed on the fly on a subpixel
scanline basis, resulting in higher quality than if you computed it on a
pixel-span basis.

Also interesting is the general idea of compositing many images at the
same time. Ie., you would tell pixman to composite a full "expression":

     solid IN (polygon1 IN polygon2 IN polygon3) OVER dest

that could be arbitrarily complicated. This is especially interesting in
combination with a JIT compiler.

> Extra note:
> If we want pixman to be more powerful and general stateless
> backend for vector and raster graphics library, I think it would be
> good to introduce GPU-backend with pixman path image. That can
> give us full chance of optimizing shape filling pipeline. But if we
> consider S/W rendering only, polygon image would be sufficient.

The roadmap for pixman is definitely to become a more powerful and
general stateless backend for vector and raster applications.

> I don't think that those two approaches are conflicting. We can
> support both interfaces. Each of them have pros and cons.

Agreed.


Soren