X-Server 1.5.0 very sluggish

Owen Taylor otaylor at redhat.com
Mon Sep 15 11:06:35 PDT 2008

On Mon, 2008-09-15 at 18:58 +0200, Michel Dänzer wrote:
> On Mon, 2008-09-15 at 12:31 -0400, Owen Taylor wrote:
> > 
> > I don't have any immediate ideas, but I wanted to throw in the data
> > point that I also seem to see a sudden slowness on r300+EXA moving from
> > 1.4.99 snapshot from July 2 (current F9 packages) to 1.5.0. Somewhat
> > similar to what you describe, though not nearly as extreme. (Some
> > windows take a couple of seconds to repaint, but menus are normal.) 
> > 
> > This is leaving the radeon driver, mesa, etc, unchanged, and only
> > upgrading the X server.
> > 
> > The slowness seems to be triggered by rendering UI elements in the GTK+
> > theme I'm using (Clearlooks, AFAIK) ... so it would be some sort of
> > problem with Render acceleration of gradients, masks, or similar. 
> > 
> > Looking at sysprof output, most of the time during sluggish redrawing
> > is spent migrating pixmaps from video memory into system memory inside a
> > Composite operation, so it appears that for some reason, software
> > fallbacks are being triggered. The sysprof output, unfortunately doesn't
> > have enough detail to be able to tell why that is happening.
> Can one of you guys bisect this regression?

Working on it ... right now it looks like:

 - XShm pixmaps got accidentally reenabled in the course of 
   Adam's changes
 - Someone (maybe GTK, having tracked it down yet) is taking advantage  
   of that by creating a shared pixmap and using it as the source for
   a composite operation.
 - That is not handled well in EXA and triggers migration of the
   destination back to system memory. (*)

- Owen

(*) One of the many cases where we'd be better off creating temporaries
in video memory to avoid migration.

More information about the xorg mailing list