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

[Siarhei Siamashka]

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:
http://cgit.freedesktop.org/~siamashka/pixman/log/?h=overlapped-blt

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
implementation):

$ 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