Bug#394349: compiz: some windows are unaffected
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
Reply to: