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

[Jonathan Morton]

On Wed, 2009-06-03 at 12:42 +0300, Siarhei Siamashka wrote:
> Hi,
> 
> What kind of guarantees (or the lack of) pixman and XRender are supposed to
> provide when dealing with overlapping parts of images?
> 
> 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.

> What do you think about the whole issue?

We're seeing exactly this kind of problem when scrolling in Firefox.  We
can speed up the primitives that Firefox uses to draw, but at the moment
scrolling is limited by the interface from Xorg to Pixman used for
XCopyArea.  We know that Pixman is being used, because we see a
performance improvement when we turn on a NEON version of pixman_blt().

When an overlapped XCopyArea is issued - as is typical for a short
scroll in any direction - XCopyArea breaks up the request into
individual scanline fetches and puts.  This produces correct results,
but because each scanline is done via two full Pixman call chains, it is
hideously slow.  By that I mean that it can be about a third of the
speed of a full copy-out followed by copy-back.

(In fact, I think XCopyArea does this regardless of whether the areas
actually overlap, if the source and dest images are the same.  Ugh.)

If Pixman were able to guarantee that "reasonable" overlapped copy
requests would behave like a "move", this highly inefficient special
case could be removed from Xorg, and there would be more opportunities
for optimisation within Pixman itself, where they are more likely to be
accepted.  "Reasonable" in this case could mean that the same image must
be referenced for both ends, rather than the "accidental overlap"
scenario.

The row-stride argument of the blitters already accepts a signed
argument, so in theory this should work just fine.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com