Bug#394349: compiz: some windows are unaffected
> Michel Dänzer a écrit :
>
>>> Did a killall compiz.real, which restarts it. The behaviour is the same
>>> as before : the first terminal is ok, the second one is sluggish.
>>>
>>
>> Note how both windows were created before the second compiz instance
>> started, which contradicts your theory.
>>
>
>Not really, this latest procedure just proves that the second window's
>bad behaviour survives a change of "managing compiz" (please forgive my
>"less-than-optimum" vocabulary).
>
>The first window already behaved nicely even under compiz. More
>important, the first window was still created out of compiz, the second
>one in compiz, which is the only difference that I can see between the two.
>
>I am really not an expert in development, even less in graphics
>development, but the only explanation that I can see is that compiz
>initializes or configures something differently than metacity. Or maybe
>it is the other way : maybe gnome-terminal initializes something
>differently when under compiz (although I don't know if gnome-terminal
>is aware of the window manager).
>
>Which program creates that difference I don't know, but it leads to a
>working or broken behaviour. Maybe this is linked to a poorly designed
>or even broken driver, maybe not. But the good behaviour of the first
>window, even after multiple compiz restarts proves that it *can* work right.
>
>Again, if you think that it's not worth debugging, especially because of
>the closed driver, just leave it closed. Or better yet, split it from
>the original bug report (after all I think it's clearly another issue)
>and tag it "won't fix", after all this is just a corner case of one
>specific application and a closed driver which doesn't come from debian.
>But that way it's clearly documented, and I can report whatever I find
>with future versions of the involved programs.
>
>Thanks,
>--
>Rémi
>
I should preface this by saying that I'm not running Debian (or a
derivative), but I do have some information to provide.
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.
It should also be noted that this problem affects XFCE's terminal
emulator as well.
Now, the details...
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)"
Regards,
Lachlan
Reply to: