GNOME Bugzilla – Bug 123903
using transparency with "no picture" background causes slowness
Last modified: 2007-03-10 20:39:48 UTC
If you use transparency in gnome-terminal with no GNOME desktop background image, gnome-terminal gets *really* *really* slow. Opening a new window takes 5-10 seconds, typing is lagged and refreshing the window on expose events also takes a very long time. steps to reproduce: (1) be someone who uses gnome-terminal transparency with a background image (2) right click on your desktop, go into change desktop background (3) click on "no picture" (4) type into your existing terms. fire up some new ones. things get laggy here.
I have followed your steps, and I cannot reproduce the behaviour you are seeing. Can you provide any more detail?
I'll add that I see this behavior when I select "No Picture" in Background Preferences, and select "Solid Color" in the background style. gnome-terminal background is pseudo-transparent. Using gnome-terminal-2.4.1.
I confirm the same symptoms under debian unstable.
I can reproduce this (it's related to the Solid Color option: that was missing in the original report, and I was using a gradient...) I think this is happening because vte mishandles the case when the root background has no image and is solid: in that situation, the height and width of the root pixmap are 1 and 1 (see vte/src/vtebg.c:vte_bg_get_pixmap, in the VTE_BG_SOURCE_ROOT case) I'll look into that.
I've found the cause of this problem. It seems to be a design problem. The vte code is actually doing the right thing. The vtedraw routines (in vtexft.c for example) draw the transparent background by doing XCopyArea from the background image to the terminal window. In the case of a tiled background image, it just does a XCopyArea of the image however many times is needed to fill the entire terminal window. In the event of a 1x1 tiled background image and a 500x300 pixel window, that's 150000 calls to XCopyArea. The 'solid colour' option is implimented as a 1x1 tiled image. This problem actually occurs for any 1x1 tiled image (or any 2x2 tiled image... it's just 1/4th as bad...) This behaviour obviously needs to be made more intelligent.... maybe some kind of an offscreen cache of what the background looks like (stored as one big pixmap, the size of the screen).... Or maybe, seeing as the core of the problem is the 10000s of requests to the X server (XCopyArea talks to the X server...) the code could just be changed to ask the X server for the pixmap once, take a local copy of it, do the replication internally and then throw the entire result back at the X server in one go. I'm not sure about how to manipulate X drawables, but I might look into it later tonight. Does anyone have any better ideas than one of the two listed above?
Created attachment 25957 [details] [review] possible fix This patch fixes the bug (or more accurately, reduces its severity by a factor of at least 65536). It's a bit of a compromise. If the image being drawn is smaller than 256x256 pixels then the pixbuf that holds it is replaced by one that is atleast 256x256 pixels and contains a tiled version of the image. In this way the number of calls to XCopyArea is kept down. It's not ideal, but it works very well for me.
*** Bug 138870 has been marked as a duplicate of this bug. ***
*** Bug 140305 has been marked as a duplicate of this bug. ***
*** Bug 140511 has been marked as a duplicate of this bug. ***
Accepted. Moved some bits around to make the fix apply to images, too, just in case we get pathological pixbufs. Thanks!
*** Bug 137162 has been marked as a duplicate of this bug. ***
*** Bug 141099 has been marked as a duplicate of this bug. ***
*** Bug 150287 has been marked as a duplicate of this bug. ***
This behavior is occuring again for me using Ubuntu Dapper with all updates. By setting the desktop wallpaper to solid Gnome Terminal causes Xorg to starve a gcc running a compile in a terminal by consuming ~70% cpu. -- Gnome gnome-terminal 2.14.2 with Xorg: X Window System Version 7.0.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.0 Build Operating System:Linux 2.6.15.7 i686 Current Operating System: Linux siggy 2.6.15-26-386 #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 i686 Build Date: 16 March 2006 using. (--) Chipset MOBILITY RADEON 9000 (M9 4C66) found
Regression -- reopening.