gnome-terminal is very sluggish with compositing manager

[Elijah Epifanov]

edit: All this applies to composited screens (compiz, metacity 2.22 w/compositing, xcompmgr)

gnome-terminal (+xfce-terminal, dunno since which release, 2.18 already did) and many other gnome apps (since gnome 2.22 release) are mapping and resizing with X glitches, depending on that applications' window area.

I tried many xorg.conf variations (almost all options found in xorg.conf attached in bug report were set to different values in many variations), nothing helped.

After hours of investigating, I found that probably GetImage with non-zero x and y causes problems. Take a look at this:

$ x11perf -getimagexy100 -getimage100
x11perf - X11 performance program, version 1.5
The X.Org Foundation server version 10400090 on :0.0
from hajile
Thu Mar 27 04:00:00 2008

Sync time adjustment is 0.1043 msecs.

  24000 reps @   0.2503 msec (  3990.0/sec): GetImage 100x100 square
  24000 reps @   0.2494 msec (  4010.0/sec): GetImage 100x100 square
  24000 reps @   0.2542 msec (  3930.0/sec): GetImage 100x100 square
  24000 reps @   0.2496 msec (  4010.0/sec): GetImage 100x100 square
  24000 reps @   0.2541 msec (  3940.0/sec): GetImage 100x100 square
 120000 trep @   0.2515 msec (  3980.0/sec): GetImage 100x100 square

      8 reps @ 1177.7100 msec (     0.8/sec): GetImage XY 100x100 square
      8 reps @ 1175.9952 msec (     0.8/sec): GetImage XY 100x100 square
      8 reps @ 1173.9538 msec (     0.9/sec): GetImage XY 100x100 square
      8 reps @ 1174.2246 msec (     0.9/sec): GetImage XY 100x100 square
      8 reps @ 1173.8732 msec (     0.9/sec): GetImage XY 100x100 square
     40 trep @ 1175.1514 msec (     0.9/sec): GetImage XY 100x100 square

I'm ready to try everything you ask on 2 nvidia systems (laptops, one with quadro fx 570m, other with quadro nvs 110m) just to get gnome + compiz + awn working.

PS:
in bug report, I have RenderAccel set to false, I just tried it but 'true' doesn't affect anything related to this bug report.

[philipl]

You need to change InitialPixmapPlacement - probably to 2. There was a change made in the most recent X server for security reasons that causes the default placement policy to trash really bad.

[Elijah Epifanov]

Forgot to say that I tried all InitialPixmapPlacement policies.

0 - mapping is slow, gtk apps generally fast
1 - the same (but, I have feeling that mapping is somewhat faster)
2 - mapping is fast, gtk apps much slower, avant-window-navigator resizes VERY slow (100% cpu for tens of seconds when bar resizes)
3 - don't remember, but not better than 0, 1 or 2.
4 - all is slow, gfx artifacts

[pigeon]

For last resort and a quick workaround, if you want compositing in general, but don't want gnome-terminal and the like to use it, try setting the environment variable XLIB_SKIP_ARGB_VISUALS=1 before for running it.

[winggndm]

I have had this same problem for a while. I traced it down to a security patch applied to the xserver. Take a look at
http://forums.gentoo.org/viewtopic-t...ighlight-.html

[txf]

So this problem occurs on any terminal (or window) that has argb visuals? I'm thinking that maybe its the reason konsole in kde4 is so sluggish...

[Elijah Epifanov]

Originally Posted by winggndm

I have had this same problem for a while. I traced it down to a security patch applied to the xserver. Take a look at
http://forums.gentoo.org/viewtopic-t...ighlight-.html

the most interesting patch is missing (404)