There are some people (including myself) on Gentoo Forums, who reported that terminal is very slow if compositor is not used and that 0.2.5.8rc2 does not have this problem. It seems that the problem is triggered when a rgba-colormap is set on non-composited screen. I'll attach a patch, which resolves the problem for me and at least one more person on the forums.
Created attachment 966 speed-up.patch this just adds a check if the screen is composited and only in this case sets the default colormap.
With this patch you'd need to restart Terminal after enabling the compositor, which is not really what I want. Did you try disabling the composite extension in your xorg.conf instead?
Yes, commenting out the composite extension in xorg.conf did solve the problem for me. I guess some people would prefer to leave it activated in order to "play around" with beryl from time to time, while otherwise still relying on their plain window manager for serious work ;-) So from that perspective the submitted patch makes sense.
Sorry for the late response. I could confirm that commenting the composite extension works, but I hope that there could be found a better solution to the problems (ie not editing xorg.conf and not needing to restart terminal after enabling compositor)...
(In reply to comment #1) > Created an attachment (id=966) [details] > speed-up.patch > > this just adds a check if the screen is composited and only in this case sets > the default colormap. Just want to confirm: Without the patch, Terminal-0.2.7svn-24701 showed the behaviour you described (composite extension enabled, not using compositor, gentoo system). I reinstalled from svn and patched Terminal-0.2.7svn-24832 and the old performance is restored, no more cpu-intensive delays. IMHO restarting a Terminal session is much less trouble than restarting X and changing X configuration so unless there is a better solution, I vote for applying this patch. Thanks for the patch!
There is the same problem on Xubuntu Feisty Fawn (alpha). I have Xfce 4.4 installed on Edgy, but there is no problem with the Terminal. Maybe there is a new X version on Feisty Fawn, that produces the problem?
*** Bug 3153 has been marked as a duplicate of this bug. ***
I doubt it's an X problem. I used Terminal on Kubuntu Edgy Eft with no problem, but it has this issue (when compositor is enabled) on Fedora Zod. Both Zod and Edgy have the same version of X, that is, 7.1.
Hi there ! Just to ping this bug, since I discovered it on my Debian(Unstable) box. I a dual head configuration, and a workspace with two full screen terminals. You can imagine this is not bearable to wait for about one second before the workspace get drawn when I switch on it. I'm using 0.2.6 version provided by Debian, and yes the Composite X extension is on, but the last time I tried to remove it, it didn't solve the problem :( Do the assigner think more information should be needed ?
Hi again, I have to say that I was thinking that commenting out the Composite line in the xorg.conf disable compositing... I just forgot that composition is enabled by default in this release of X.org :/ Switching it explicitly to off solves the slowness of the workspace refresh.
Here the worskpace switching is slow even when composite is activated in xfwm tweaks...
Hi everyone, Just to confirm, I have this issue on a Debian lenny/testing mixed with unstable packages (only for the nvidia-legacy and xorg-core bits). Turning off compositing in xorg.conf did solve the problem: Section "Extensions" Option "Composite" "Disable" EndSection
Please see this short thread on the Gentoo forums: http://forums.gentoo.org/viewtopic-p-5089240.html My guess is that Terminal uses the a 'wrong' method of achieving transparency, but I am afraid that I do not know enough about X.Org transparency coding to say with certainty. What I do know is that when I enabled (i.e. set to value of 1) XLIB_SKIP_ARGB_VISUALS, workspace switching was instant again, transparency in Terminal was broken, and transparency for everything else in Xfce4 continued to work perfectly.
Also reproducible on my two boxes, where compiz-fusion is running as a window manager. Therefore, turning off the composite extension is not an option here. I just gave x11-terms/gnome-terminal-2.18.4 a try and it shows exactly the same behavior, so this seems to be a problem of an underlying library...
*** This bug has been marked as a duplicate of bug 5529 ***