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