[Pixman] [RFC] A spans interface for pixman

Taekyun Kim podain77 at gmail.com
Wed Aug 17 07:21:47 PDT 2011

I've looked into Chris's initial version and can give leave some
comments.And I also have some questions about pixman polygon
image to Sørenin below comments.
So, let's start.

On 08/01/2011 08:49 PM, chris at chris-wilson.co.uk wrote:
> Currently Cairo generates a temporary alpha mask for any non-pixel
> aligned shape. In those circumstances, it would be faster if we could
> pass the shape-information to pixman and have it composite in a
> single-operation. (With secondary benefits for reducing the number of
> sampled pixels.)  A further goal is to be able to reduce the unaligned
> clipping operation to a single pass as well. Furthermore it will also be
> useful to supply a unified-opacity value to support a "global alpha" when
> our source/mask channels are already utilised.  One suggested approach
> is to create a polygon image and have pixman generate spans internally.
> This satisfies compositing a polygon in a single pass, and if we
> additionally add clip-polygons we can accomplish the further goal of
> single-pass clipping as well.

I totally agree with that current pixman interface is not sufficient for
efficient polygon scan rasterizaion.Sampling every pixels inside of
mask extents is huge overhead. And some applications require
additional global opacity to be applied while mask is used for some
other purposes. With current pixman, we have to do this by
rendering things into a temp image and then compositing to
destination with solid mask with opacity alpha value (multi-pass).

Currently, there are two approaches to support polygon filling.
pixman polygon image vs spans.

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

1. If polygon image is used as a src, is it treated as just a8 image?
2. If polygon image is used as a dest, is it converted to bits image?
3. What if pixman_image_get_data() is called on polygon image?
4. How can I fill intersection of two (or more) polygon images?

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.

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

> I've push an intiial implementation to
>    git://people.freedesktop.org/~ickle/pixman wip/spans
>    git://people.freedesktop.org/~ickle/cairo wip/spans

As I mentioned on IRC, general paths can be implemented by simply applying
combine_in just before giving scanlines to composite function if opacity 
is not
fully opaque. I think people will not want performance regressions even on
general paths.

And some additional mechanisms seem to be needed to utilize existing fast
paths. Fast paths for solid mask can be reused to support opacity by simply
combining solid color with opacity value. Solid mask is also same. 
Adding fast
paths with non-solid mask and non-opaque opacity should be sufficient 
for our

For example, over_n_8_8888 does not need to have FAST_PATH_IS_OPAQUE
flag if the function internally pre-combine opacity with solid color. 
Your C fast
paths can be modified to take advantage of existing fast paths with small
amount of effort.

> Even without optimised fast-paths, there are quite a few traces where
> passing spans to pixman is a win (where the shape only occupies a
> fraction of the mask extents and so where doing so reduces the number of
> pixels we have to sample; and the opaque portions still hit the existing
> fast paths.)
> -Chris

I will also evaluate the performance of HTML5 canvas bench.
Thank you Chris!

Best Regards,
Taekyun Kim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20110817/dcd67128/attachment.htm>

More information about the Pixman mailing list