On Wed, 2007-11-14 at 00:47 +1100, Predatory Kangaroo wrote: > > First, Michel, Rémi's statements aren't contradictory, as the second > terminal was the one that was created while Compiz was running. It > doesn't matter that Compiz was started again afterwards.
The point is: The second compiz doesn't know whether a previous instance was running when either window was created. And even the first instance doesn't have any direct influence on how either window is created. > It should also be noted that this problem affects XFCE's terminal > emulator as well. Presumably because like gnome-terminal, it uses VTE for the actual terminal window. > If a terminal emulator is started before compiz starts, it doesn't > even try to do fancy transparency, but just falls back to copying the > root window. > If the terminal emulator is started after compiz starts, then resized, > the whole X server locks up for a fraction of a second. > Other programs that use true transparency have the exact same symptoms > (I can provide a sample program if needed). > > I understand (and agree with) your reasoning, Michel, that it seems to > be an nVidia issue, but I thought this would help close the bug. > Oh, and just to help confirm it, on my system, each of the windows > that exhibits the problem has depth 32, and though the exact colourmap > varies, xwininfo -all reports it as "Colormap: xxxxxxxx (not > installed)" That's what I was getting at in a previous post, but I assumed it would only matter when transparent background is actually enabled... looks like that's not the case, which can probably be considered a bug in VTE or the terminal apps - I think the (non-)presence of a compositing manager should generally be adapted to dynamically. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer