The window is not always correctly refreshed when switching between workspaces

[Raphaël Hertzog]

I use terminator maximized in my first workspace. I have a Firefox 3 in my second work-space and I switch between both with a keyboard shortcut quite heavily. And very regularly, I have to see the content of my firefox window in my terminator window... I have to force a refresh somehow (changing workspace a second time, or minimize/maximize) to see the real content of my terminal.

Attached is a screenshot: on the left pane, I'm supposed to have mutt (you see it on the top, a few lines...), yet the rest is filled with the content of some web page... (except for the central part where some other windows was temporarily displayed through ALT+Tab and that forced a partial refresh...).

It it is somehow related to GTK, as only some GTK widgets have that effect... for example with xchat, I only get the input field displayed on top of my terminal and with firefox only the part that displays the web page (the tabs and toolbars are never displayed above the terminal).

I use terminator 0.9-1~beta1.7 (Debian package from Nicolas Valcárcel <email address hidden>). libgtk2.0-0 is at version 2.12.10-2. I'm using current Debian Sid.

[Nicolas Valcarcel (nvalcarcel)]

It fails when not using compiz.

[Chris Jones (cmsj)]

I can't reproduce this using the intel Xorg driver in hardy with or without Compiz enabled.
It's also a bit odd because without compositing, the window will be forced to redraw when it is made visible, so it ought to paint over these artifacts.

nxvl: are you seeing this?

[Nicolas Valcarcel (nvalcarcel)]

Yep i had this bug earlier, did you remember? It started after the compiz transparency bug. I send you some screenshots also, but as no one seems to have it i thought it was a problem of my computer (i saw it at work and home)

[Raphaël Hertzog (hertzog)]

On Wed, 25 Jun 2008, Chris Jones wrote:
> I can't reproduce this using the intel Xorg driver in hardy with or
> without Compiz enabled. It's also a bit odd because without
> compositing, the window will be forced to redraw when it is made
> visible, so it ought to paint over these artifacts.

I'm also using the "intel" driver (on a 24" external screen).
I have version 2:2.3.2-1 of xserver-xorg-video-intel.
And lspci says this about my VGA controller:
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

And indeed, I'm not using Compiz. I can do more tests if needed.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

[Chris Jones (cmsj)]

nxvl: which graphics card/driver do you use?

I'm seriously tempted to suggest this is a driver bug, but it's possible (by which I mean quite likely) that my understanding of how X causes things to be redawn is wrong.

[Raphaël Hertzog (hertzog)]

On Fri, 27 Jun 2008, Chris Jones wrote:
> I'm seriously tempted to suggest this is a driver bug, but it's possible
> (by which I mean quite likely) that my understanding of how X causes
> things to be redawn is wrong.

Given that I never had this problem with gnome-terminal, I'm not sure it's
driver problem. It's more likely a problem with the python-vte binding or
something like that.

ii python-vte 1:0.16.14-1 Python bindings for the VTE widget set
ii python-gnome2 2.22.0-1 Python bindings for the GNOME desktop environment

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

[Nicolas Valcarcel (nvalcarcel)]

I've had this problem on a nvidia using a mixture of drivers (the oficial nvidia one, then with the one shiped with ubuntu) and with an intel (845 IIRC)

[Chris Jones (cmsj)]

well i guess that pretty much rules out driver bugs.

[Chris Jones (cmsj)]

I will see if I can figure out gtk events for when the whole window gains/loses focus and then we can try and make the entire window redraw when it gains focus, which would hopefully get rid of this.

Could someone confirm that when this happens, if you drag the terminal separators, does it then redraw at least one of the terminals correctly? (or anything else you're able to do to fix it, like minimising, alt-tabbing, etc)

[Raphaël Hertzog (hertzog)]

On Fri, 27 Jun 2008, Chris Jones wrote:
> Could someone confirm that when this happens, if you drag the terminal
> separators, does it then redraw at least one of the terminals correctly?

Yes, I confirm it.

--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

[Nicolas Valcarcel (nvalcarcel)]

Yep, you need to move something in that desktop to make it clean
again. It only happens when changing from other desktop.

On Fri, Jun 27, 2008 at 4:22 PM, Raphael Hertzog <email address hidden> wrote:
> On Fri, 27 Jun 2008, Chris Jones wrote:
>> Could someone confirm that when this happens, if you drag the terminal
>> separators, does it then redraw at least one of the terminals correctly?
>
> Yes, I confirm it.
>
> --
> Raphaël Hertzog
>
> Le best-seller français mis à jour pour Debian Etch :
> http://www.ouaza.com/livre/admin-debian/
>
> --
> The window is not always correctly refreshed when switching between workspaces
> https://bugs.launchpad.net/bugs/242852
> You received this bug notification because you are a member of
> Terminator, which is subscribed to Terminator.
>

[Chris Jones (cmsj)]

I have just pushed a fix to trunk which may fix this - could someone test please?

[Raphaël Hertzog (hertzog)]

On Sun, 29 Jun 2008, Chris Jones wrote:
> I have just pushed a fix to trunk which may fix this - could someone
> test please?

I applied the change locally (just took the diff of the two changesets and
hand-applied it). I still have the problem. :-|

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

[Chris Jones (cmsj)]

Ok I think it would be helpful to find out if this is something we've always had, or something we've broken
Is this reproducible with 0.8.1? If so, could someone try some different revisions since 0.8.1 to see where it broke?

[Nicolas Valcarcel (nvalcarcel)]

I experienced it with 0.8.1 after the compiz transparency fix.

On Tue, 2008-07-01 at 21:48 +0000, Chris Jones wrote:
> Ok I think it would be helpful to find out if this is something we've always had, or something we've broken
> Is this reproducible with 0.8.1? If so, could someone try some different revisions since 0.8.1 to see where it broke?
>
--
aka nxvl
Peruvian LoCo Team
Key fingerprint = BCE4 27A0 D03E 55DE DA2D BE06 891D 8DEE 6545 97FE
gpg --keyserver keyserver.ubuntu.com --recv-keys 654597FE

[chantra (chantra)]

0.8.1 was released on the 20/02/2008 so it brings us to rev 203,204,205

205 was a big chunk but it looks like we can narrow down the searches
to:
revno: 205
committer: Chris Jones <cmsj@waishou>
branch nick: trunk
timestamp: Sun 2008-02-24 22:10:39 +0000
message:
  My tree has diverged a little while pulling in these changes. also
some text editors are being unhelpful here with tabs. This should be two
spaces for new items and 4 for continuations.I keep getting caught out
by vim auto-indenting tabs for some reason.
    ------------------------------------------------------------
    revno: 200.1.8
    committer: Thomas Meire (blackskad)
    branch nick: trunk
    timestamp: Sun 2008-02-24 17:44:51 +0100
    message:
      Switch transparency-mode when compositing is turned off or on.
(Addition to the fix for LP #190946)
    ------------------------------------------------------------
    revno: 200.1.7
    committer: Thomas Meire (blackskad)
    branch nick: trunk
    timestamp: Sat 2008-02-23 22:54:39 +0100
    message:
      Add support for real transparency when using a composited
environment. (Fixes LP #190946)

On Wed, 2008-07-02 at 00:37 +0000, Nicolas Valcárcel (nxvl) wrote:
> I experienced it with 0.8.1 after the compiz transparency fix.
>
> On Tue, 2008-07-01 at 21:48 +0000, Chris Jones wrote:
> > Ok I think it would be helpful to find out if this is something we've always had, or something we've broken
> > Is this reproducible with 0.8.1? If so, could someone try some different revisions since 0.8.1 to see where it broke?
> >
> --
> aka nxvl
> Peruvian LoCo Team
> Key fingerprint = BCE4 27A0 D03E 55DE DA2D BE06 891D 8DEE 6545 97FE
> gpg --keyserver keyserver.ubuntu.com --recv-keys 654597FE
>
--
http://www.debuntu.org

Debuntu deb's repository

[Chris Jones (cmsj)]

I've just pushed a patch which backs out the RGBA stuff for window transparency - could you guys test now and let me know if it makes any difference?

[Raphaël Hertzog (hertzog)]

On Wed, 02 Jul 2008, Chris Jones wrote:
> I've just pushed a patch which backs out the RGBA stuff for window
> transparency - could you guys test now and let me know if it makes any
> difference?

I'v been running this for two days and it seems to have solved the problem
for me!

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

[chantra (chantra)]

hi Raphael,

thanks for the feedback.
As this issue did not seem to hit many people, maybe the "breaking" part could be remerged to the code.
And then, we could add yet another conf parameter to disable it.

[Chris Jones (cmsj)]

Emmanuel committed the transparency code back into trunk and added an option:

enable_real_transparency

so if you are seeing this refresh bug, you should place:

enable_real_transparency = False

in $HOME/.config/terminator/config

and it will not try to use the real transparency. Unfortunately I don't think there is a way we can automatically detect which systems will be affected by this bug, so it'll have to be a config workaround.

[Raphaël Hertzog (hertzog)]

On Sun, 06 Jul 2008, Chris Jones wrote:
> and it will not try to use the real transparency. Unfortunately I don't
> think there is a way we can automatically detect which systems will be
> affected by this bug, so it'll have to be a config workaround.

Urgh! I'll add the option but it's definitely not the right thing to do.

It might well be that your code is not at fault, but we might have
discovered a bug in gtk or X and you should try to isolate it and report
it where it is due.

And you're best placed to explain what you tried to do with this bit of
code that is causing problems.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

[Chris Jones (cmsj)]

I agree it's not ideal. The alternative is that the default is False and people who use transparency think we suck for not supporting RGBA.
Neither option seems right to me, but I will think some more about switching the default to False so the people seeing this bug aren't affected at all.

[Chris Jones (cmsj)]

0.9 has now been released and should fix this.

[psypher (psypher246)]

hey guys. Here is my problem. before on ubuntu hardy i used terminator all day long, fullscreen and i really really loved the fact that when it's fullscreen the transparency would show me my beautiful iconless desktop wallpaper. now with intrepid (and i'm guessing a new version of terminator) I either have transparancy off or i can turn it on with the workaround in this thread but the transparency shows me the apps below. Now I see thats what it's supposed to do :( How can i make it that it shows me my desktop wallpaper instead of the apps thats really behind it?

it used to be so cool.

[Chris Jones (cmsj)]

psypher: it would be better to report a new bug, or ask a question, instead of commenting on an existing bug report which is already fixed.
I would suggest you configure a background image in Terminator that's the same as your desktop background, and then set the darkness config option.