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

[Jonathan Morton]

On Mon, 2009-10-26 at 17:52 +0100, Soeren Sandmann wrote:

> > write-through cache for it (with a simple kernel patch) improves scrolling
> > and moving windows performance by 4x-5x factor (unless shadow framebuffer is
> > used, which is also not good for performance). 
> 
> What is the issue with the shadow framebuffer? It does add some extra
> memory traffic from the final copy, but I would have thought that
> everything else becoming much faster, would more than make up for it.

The shadow framebuffer has one additional source of overhead: the
damage-region tracking it does to accumulate multiple updates into a
single post-copy.  If you do a lot of small writes to the shadow, the
damage region gets complex and slows everything down.  We have a trivial
pathological reproduction case, involving spraying random small
rectangles all over the screen.

It also seems that enabling shadow also forces on backing stores, which
is another unnecessary memory overhead and probably involves more
copying.

It is of course possible to imagine a "sloppy damage" tracker, to reduce
overhead by limiting damage-region complexity.  ISTR writing one for a
VNC server a long time ago, simply because I didn't want or need precise
region tracking.

If we don't want to deal with uncached framebuffers in Pixman, and
nobody seems entirely comfortable with cached physical framebuffers,
maybe it's worth my digging my old code out and seeing if it can be
adapted.

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