[Pixman] [PATCH 1/3] Add CLEAR and SRC linear interpolation operators

Søren Sandmann sandmann at cs.au.dk
Thu Sep 15 04:26:09 PDT 2011

Chris Wilson <chris at chris-wilson.co.uk> writes:

>> Did you see Taekyun Kim's reply to this? He proposes this API:
>>      pixman_image_composite_xrender(op, src, shape, clip, dst)
>>      pixman_image_composite_bounded(op, src, shape, clip, dst)
>>      pixman_image_composite_simple(op, src, shape, clip, dst)
>> instead, which would add direct one-pass support for all of cairo's
>> compositing schemes, including clip masks.
> You're encoding operator semantics into the function call and adding
> parameters for the rest? 

Yes, basically. It's more or less a direct translation of the three
compositing equations that cairo uses into function calls.

> Although pixman could benefit from faster
> methods of rendering polygons, I do not see this as actually reducing
> the amount of code inside Cairo as GL is effectively the lowest common
> demoniator. (Though we desparately need a change in the Render protocol
> so that we can feed polygons to the server more cheaply and that in turn
> merits similar changes in pixman.)
> My gut feeling is that interface is too restrictive. You may as well
> skip polygon images and go to paths and boolean geometry. In the
> meantime providing an interface that matches what Cairo uses today is
> also going to be useful for when you replicate Cairo inside pixman.

The proposed interface is basically orthogonal to the question of
polygons in pixman. Even without polygons or spans in pixman, the
proposed interface is a superset of what cairo needs today in order to
implement fill() and stroke() in one pass (after rasterizing the

The polygon question is just about how the shape and clip images could
be given in a more efficient manner. The three compositing equations
that cairo uses are still the same in either case.


More information about the Pixman mailing list