[cairo] [RFC] Pixman & compositing with overlapping source and destination pixel data

Siarhei Siamashka siarhei.siamashka at gmail.com
Mon Oct 19 14:13:15 PDT 2009

On Thursday 04 June 2009, Soeren Sandmann wrote:
> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> > What kind of guarantees (or the lack of) pixman and XRender are supposed
> > to provide when dealing with overlapping parts of images?
> (Adding xorg-devel). See this thread:
>     http://lists.freedesktop.org/archives/xorg/2008-October/039346.html
> The guarantee that I would suggest for Render and pixman is that if
> any pixel is both read and written in the same request, then the
> result of the whole request is undefined, except that it obeys the
> clipping rules.
> > The practical use case could be scrolling of data inside of a single big
> > image. If rendering with overlapped source and destination areas is not
> > supported, a temporary image has to be created to achieve expected result
> > and this is an additional performance hit.
> Yes, scrolling is one thing that the current pixman API doesn't really
> provide. 'pixman_blt()' only deals with cases where the source and
> destination don't overlap.
> I think the best solution is to move all of the X primitives
> (CopyArea, DrawLine, DrawArc, etc.) into pixman. For CopyArea it would
> probably look something like this:
>         void
>         pixman_copy_area (pixman_image_t *src,
>                           pixman_image_t *dest,
>                           pixman_gc_t *gc,
>                           int src_x,
>                           int src_y,
>                           int width,
>                           int height,
>                           int dest_x,
>                           int dest_y);
> and that would be guaranteed to handle overlapping src and dest. A
> pixman_gc_t would be a new type of object, corresponding to an X GC.
> pixman_blt() would then become a deprecated wrapper that would just
> call pixman_copy_area(). Same for pixman_fill() and a new
> pixman_fill_rectangles().

I'm not sure about pixman_gc_t since most of the needed operations are just
simple copies. What about starting with just introducing a variant
of 'pixman_blt' which is overlapping aware?

I created a work-in-progress branch with 'pixman_blt' function (generic C
implementation for now) extended to support overlapped source/destination
case. A simple test program is also included:

Making use of the already existing SIMD optimized pixel copy functions should
provide fast scrolling in all the directions except for from left to right.
This special case will require a SIMD optimized backwards copy.

I wonder if it makes sense to drop delegates support for pixman_blt and make
call chain shorter when introducing SIMD optimized copies? It seems to be a
little bit overdesigned here.

Running test program for the current pixman master (SSE2 optimized):

$ test/overlapped-blt-test
bpp=8, supported=0, normal_ok=0, overlapped_ok=0
bpp=16, supported=1, normal_ok=1, overlapped_ok=0
bpp=32, supported=1, normal_ok=1, overlapped_ok=0

Running test program for the pixman from this branch with generic
C version of pixman_blt (8bpp now uses a fallback to generic C

$ test/overlapped-blt-test
bpp=8, supported=1, normal_ok=1, overlapped_ok=1
bpp=16, supported=1, normal_ok=1, overlapped_ok=0
bpp=32, supported=1, normal_ok=1, overlapped_ok=0

Best regards,
Siarhei Siamashka

More information about the cairo mailing list