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.mor...@movial.com _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel