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

[Koen Kooi]

On 19-10-09 23:13, Siarhei Siamashka wrote:
> 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

Would using said branch give me 'magically' a performance boost (e.g. 
not make firefox unusably slow as it is now on an 600MHz cortex a8) or 
would I need to patch other libs (e.g. xrender) as well?

regards,

Koen