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: (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
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: (not installed)" Regards, Lachlan
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
Bug#394349: compiz: some windows are unaffected
On Mon, 2007-10-29 at 11:47 +0100, Rémi Letot wrote: > > > How is the resize performance of the two kinds of gnome-terminal > > windows after you kill and restart compiz? > > 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. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#394349: compiz: some windows are unaffected
Michel Dänzer a écrit : I thought of something that might explain the mystery: Do you happen to have transparent background enabled in gnome-terminal? Nope, the original configuration, I didn't change anything from the default config. How is the resize performance of the two kinds of gnome-terminal windows after you kill and restart compiz? 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. I also tried to restart gtk-window-decorator which didn't change anything. Thanks, -- Rémi
Bug#394349: compiz: some windows are unaffected
On Sat, 2007-10-27 at 15:33 +0200, Rémi Letot wrote:
> Michel Dänzer a écrit :
> > > All these windows cohexist in a single X session, so I don't think that
> > > it's related to the way the Nvidia driver behaves. Compiz must do
> > > something to the terminal windows it creates that metacity doesn't do,
> > > the trick is to find that difference :-)
> > >
> >
> > 'Must do' why? I don't see anything that would follow from.
>
> English is not my mother tongue, so maybe the tone is not right and
> "must do" is too categoric, but to answer your question : because
> gnome-terminal windows started before compiz are not affected, they
> behave quite normally under compiz on the same display at the same
> time.
>
> Procedure : I start gnome with metacity, then a gnome-terminal window,
> then compiz ("compiz --replace" in that terminal for example), then
> start another gnome-terminal. Both gnome-terminals are on the same
> screen at the same time with compiz, but behave very differently. The
> first one, launched before compiz, is free of any problem. The second
> one, launched after compiz, freezes my desktop for 2 seconds everytime
> I resize it.
>
> Maybe this is related to the driver, but the problem-free behaviour of
> the first terminal, even under compiz, proves that compiz can handle
> them well.
>
> Now I tested other terminals (xterm and Eterm), and none of them
> displays the problematic behaviour. There is definitely something
> strange at work between compiz, the nvidia proprietary driver, and
> gnome-terminal.
I thought of something that might explain the mystery: Do you happen to
have transparent background enabled in gnome-terminal? How is the resize
performance of the two kinds of gnome-terminal windows after you kill
and restart compiz?
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Bug#394349: compiz: some windows are unaffected
On Sat, 2007-10-27 at 15:33 +0200, Rémi Letot wrote:
> Michel Dänzer a écrit :
> > > All these windows cohexist in a single X session, so I don't think that
> > > it's related to the way the Nvidia driver behaves. Compiz must do
> > > something to the terminal windows it creates that metacity doesn't do,
> > > the trick is to find that difference :-)
> >
> > 'Must do' why? I don't see anything that would follow from.
>
> English is not my mother tongue, so maybe the tone is not right and
> "must do" is too categoric, but to answer your question : because
> gnome-terminal windows started before compiz are not affected, they
> behave quite normally under compiz on the same display at the same
> time.
>
> Procedure : I start gnome with metacity, then a gnome-terminal window,
> then compiz ("compiz --replace" in that terminal for example), then
> start another gnome-terminal. Both gnome-terminals are on the same
> screen at the same time with compiz, but behave very differently. The
> first one, launched before compiz, is free of any problem. The second
> one, launched after compiz, freezes my desktop for 2 seconds everytime
> I resize it.
>
> Maybe this is related to the driver, but the problem-free behaviour of
> the first terminal, even under compiz, proves that compiz can handle
> them well.
It makes a difference within the (GL)X implementation as well, so I'm
afraid it doesn't prove at all that the performance delta is due to
compiz.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Bug#394349: compiz: some windows are unaffected
Michel Dänzer a écrit :
All these windows cohexist in a single X session, so I don't think that
it's related to the way the Nvidia driver behaves. Compiz must do
something to the terminal windows it creates that metacity doesn't do,
the trick is to find that difference :-)
'Must do' why? I don't see anything that would follow from.
English is not my mother tongue, so maybe the tone is not right and
"must do" is too categoric, but to answer your question : because
gnome-terminal windows started before compiz are not affected, they
behave quite normally under compiz on the same display at the same time.
Procedure : I start gnome with metacity, then a gnome-terminal window,
then compiz ("compiz --replace" in that terminal for example), then
start another gnome-terminal. Both gnome-terminals are on the same
screen at the same time with compiz, but behave very differently. The
first one, launched before compiz, is free of any problem. The second
one, launched after compiz, freezes my desktop for 2 seconds everytime I
resize it.
Maybe this is related to the driver, but the problem-free behaviour of
the first terminal, even under compiz, proves that compiz can handle
them well.
Now I tested other terminals (xterm and Eterm), and none of them
displays the problematic behaviour. There is definitely something
strange at work between compiz, the nvidia proprietary driver, and
gnome-terminal. Compiz could handle it well, but wether it's worth
investigating is totally up to you, I have a replacement solution for
the moment and I won't bug you anymore :-)
I'll probably investigate the problem when any of the three contenders
is updated to see if it's solved and report here if this is the case.
Thanks for your work,
--
Rémi
Bug#394349: compiz: some windows are unaffected
On Sat, 2007-10-27 at 13:17 +0200, Rémi Letot wrote: > > But IMHO the fact that terminal windows created before compiz is > launched don't suffer from the slowdown proves that compiz *can* handle > terminal windows very well on Nvidia hardware. > > All these windows cohexist in a single X session, so I don't think that > it's related to the way the Nvidia driver behaves. Compiz must do > something to the terminal windows it creates that metacity doesn't do, > the trick is to find that difference :-) 'Must do' why? I don't see anything that would follow from. In particular, if compiz indeed does something wrong, why doesn't it affect those of us using free drivers? Generally, performance is mostly up to drivers. Until you have specific evidence that this is due to something compiz does wrong, it should be assumed to be a driver issue. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#394349: compiz: some windows are unaffected
Brice Goglin a écrit : Yes, that's strange. But the initial reporter did not complain about this, so it could just be nVidia related problem. We don't know at all what the nvidia-glx binary driver does for Compiz, so it's impossible to debug this here. Yep this could be completely unrelated to what the original reporter experienced. But IMHO the fact that terminal windows created before compiz is launched don't suffer from the slowdown proves that compiz *can* handle terminal windows very well on Nvidia hardware. All these windows cohexist in a single X session, so I don't think that it's related to the way the Nvidia driver behaves. Compiz must do something to the terminal windows it creates that metacity doesn't do, the trick is to find that difference :-) If you think (as I do now) that this is not related to what the original reporter experienced, don't hesitate to split the bug. Thanks, -- Rémi
Bug#394349: compiz: some windows are unaffected
Rémi Letot wrote: > I use the nvidia driver on a 7600go, so no EXA here. Everything is > uptodate to sid versions. > > Of course it could be a driver bug. But before closing the bug, don't > you find the fact that windows started before compiz are unaffected a > bit disturbing ? Yes, that's strange. But the initial reporter did not complain about this, so it could just be nVidia related problem. We don't know at all what the nvidia-glx binary driver does for Compiz, so it's impossible to debug this here. Brice
Bug#394349: compiz: some windows are unaffected
Hello, thanks for your answer. I use the nvidia driver on a 7600go, so no EXA here. Everything is uptodate to sid versions. Of course it could be a driver bug. But before closing the bug, don't you find the fact that windows started before compiz are unaffected a bit disturbing ? Thanks, -- Rémi begin:vcard fn;quoted-printable:R=C3=A9mi Letot n;quoted-printable:Letot;R=C3=A9mi email;internet:[EMAIL PROTECTED] tel;work:+32 81 66 55 00 version:2.1 end:vcard
Bug#394349: compiz: some windows are unaffected
Rémi Letot wrote: > Package: compiz > Version: 0.5.2-2 > Followup-For: Bug #394349 > > Hello, > > I just installed sid on my laptop and was bitten by this bug. But I have > more info. > > First of all, gnome-terminal windows are much more affected than other > applications. I do notice some slight slowdown for other apps, but > gnome-terminal has a clear 2 seconds delay between the moment I move the > border, and the moment it starts moving. After that delay the move is > quite fast but seems to happen in multiple jerky steps instead of > fluidly. During the delay everything freezes on my screen. > > Much more interresting : windows that I started before launching compiz > are unaffected. I start gnome with metacity, create some windows > (terminals are good candidates because it's so easy to spot), then start > compiz --replace in a terminal. All those windows react normaly to > resizing. But if I start another terminal it will be a hog to resize, > and freeze my display while waiting. > > Maximizing displays the same behaviour. Pre-compiz terminals are ok, > post-compiz terminals have a clear delay before maximizing. One more > symptom in this case, the maximized terminal window is blank until I > click on it. > > Ok, enough for tonight, don't hesitate to ask for more info or tests. > Actually, this bug should probably be closed nowadays. Resizing in compiz works much better with xserver-xorg-core 1.4, EXA, and drivers that implement a new DRI texOffsetStart (at least radeon since 6.7.192 and intel since 2.1.1 if I remember correctly). Which server/driver are you running? Can you try the one in unstable if you use the radeon or intel driver? You just need to add Option "AccelMethod" "EXA" to section Device of your xorg.conf. Brice
Bug#394349: compiz: some windows are unaffected
Package: compiz Version: 0.5.2-2 Followup-For: Bug #394349 Hello, I just installed sid on my laptop and was bitten by this bug. But I have more info. First of all, gnome-terminal windows are much more affected than other applications. I do notice some slight slowdown for other apps, but gnome-terminal has a clear 2 seconds delay between the moment I move the border, and the moment it starts moving. After that delay the move is quite fast but seems to happen in multiple jerky steps instead of fluidly. During the delay everything freezes on my screen. Much more interresting : windows that I started before launching compiz are unaffected. I start gnome with metacity, create some windows (terminals are good candidates because it's so easy to spot), then start compiz --replace in a terminal. All those windows react normaly to resizing. But if I start another terminal it will be a hog to resize, and freeze my display while waiting. Maximizing displays the same behaviour. Pre-compiz terminals are ok, post-compiz terminals have a clear delay before maximizing. One more symptom in this case, the maximized terminal window is blank until I click on it. Ok, enough for tonight, don't hesitate to ask for more info or tests. Thanks for your great work, -- Rémi -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compiz depends on: ii compiz-core 0.5.2-2+b1 OpenGL window and compositing mana ii compiz-gnome 0.5.2-2+b1 OpenGL window and compositing mana ii compiz-gtk0.5.2-2+b1 OpenGL window and compositing mana ii compiz-plugins0.5.2-2+b1 OpenGL window and compositing mana compiz recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
