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

[Soeren Sandmann]

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().

> Generic path in pixman fetches lines into a temporary buffer, so everything
> should be fine in horizontal direction. For vertical direction, reversing the
> order of handling lines (and using negative stride) could be also possible.
> So if overlapped rendering is to be supported, technically there should not be
> any big problems. Performance would be worse in the case when overlapped
> rendering has to be sent to the generic path, but it would provide incorrect
> (or unexpected) results in the fast path anyway. Overlapping-aware fast path
> functions can be also created.

I am not necessarily opposed to making Render guarantee correct
operation for overlapping sources and destinations if someone wants to
fix the implementation. However,

- many of the operators aren't all that useful when used with
  overlapping sources and destinations;

- to be useful for scrolling windows, applications need to get
  GraphicsExposure events, and Render currently doesn't generate
  those;

- for images with transformations, you will need to make a copy
  anyway;

- you'll need to fix the server and drivers so that they either
  implement this correctly, or fall back to software.


Soren