[cairo] [RFC] Pixman & compositing with overlapping source and destination pixel data
k.kooi at student.utwente.nl
Fri Oct 23 11:02:24 PDT 2009
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:
>> 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:
>> 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
> 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:
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?
More information about the cairo