After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 125364 - vte screens are black when initially shown
vte screens are black when initially shown
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
2.12.x
Other All
: High normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
: 130015 144498 156265 158472 165387 169207 317463 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-10-24 04:05 UTC by Mariano Suárez-Alvarez
Modified: 2007-01-22 20:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vte screen painted black (52.44 KB, image/png)
2003-10-24 04:07 UTC, Mariano Suárez-Alvarez
  Details
redraw vte screen when unobscured visibility event is caught (709 bytes, patch)
2004-10-27 23:41 UTC, Jon Nettleton
committed Details | Review
update the color scheme earlier in the show (1.06 KB, patch)
2007-01-22 10:00 UTC, Mariano Suárez-Alvarez
committed Details | Review

Description Mariano Suárez-Alvarez 2003-10-24 04:05:42 UTC
Using gtk HEAD as of yesterday, and gnome-terminal HEAD, every once in a
while I get a black screen when opening a tab in gnome-terminal, as in the
following screen shot. As the screen gets repainted, it is painted in a
white background, as expected. This is 0.11.10
Comment 1 Mariano Suárez-Alvarez 2003-10-24 04:07:26 UTC
Created attachment 20894 [details]
vte screen painted black
Comment 2 Mariano Suárez-Alvarez 2004-01-27 21:24:21 UTC
*** Bug 130015 has been marked as a duplicate of this bug. ***
Comment 3 Bart Martens 2004-02-16 22:13:39 UTC
This bug is currently in Fedora Core 1, with 
vte-0.11.10-4
gnome-terminal-2.4.0.1-1

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100420
Comment 4 Ben Williams 2004-02-26 00:58:09 UTC
I get the same behaviour on my Fedora Core 1 system (me, too!) so it's
not a system-specific thing. I've got vte-0.11.10-4 and
gnome-terminal-2.4.0.1-1 as well.

Redhat's bugzilla entry for this basically just says "the gnome guys
are aware of it".

executing `reset` at the terminal sets the background colour back to
white as it should be.
Comment 5 Mariano Suárez-Alvarez 2004-06-17 01:18:31 UTC
*** Bug 144498 has been marked as a duplicate of this bug. ***
Comment 6 Evert Verhellen 2004-06-17 16:25:29 UTC
Steps to reproduce the problem are described in bug 144498.
Comment 7 Jon Nettleton 2004-10-27 23:39:14 UTC
I have pretty basic gui programming skills, but was tired of the nagging bug and
here is my take on what is going on.  I am a fedora list and have also posted my
"solution" to their bugzilla.

This issue seems to be caused by a race condition between the
visibility event and the configure-event.  The terminal knows it is
visible, and the vte_terminal_configure_toplevel callback is attached,
but the configure-event never happens.  My most elegant solution has
been to run vte_invalidate_all on the terminal when the visibility
event is caught and it's state is UNOBSCURED.
Comment 8 Jon Nettleton 2004-10-27 23:41:21 UTC
Created attachment 33150 [details] [review]
redraw vte screen when unobscured visibility event is caught

this is against the most recent vte source from fedora.  I think it will patch
against gnome cvs as well.
Comment 9 Mariano Suárez-Alvarez 2004-10-31 11:32:32 UTC
*** Bug 156265 has been marked as a duplicate of this bug. ***
Comment 10 Mariano Suárez-Alvarez 2004-11-17 01:14:53 UTC
*** Bug 158472 has been marked as a duplicate of this bug. ***
Comment 11 fast suzuki 2005-01-23 17:52:51 UTC
Is this going to be fixed? The bug remains in 2.8.2.
Comment 12 Vincent Noel 2005-01-27 17:37:59 UTC
*** Bug 165387 has been marked as a duplicate of this bug. ***
Comment 13 Christian Neumair 2005-01-31 16:05:31 UTC
I still see this behavior. Nalin?
Comment 14 Alvaro del Castillo 2005-02-04 05:56:10 UTC
In Ubunty hoary with:

acs@delito:~$ dpkg -l | grep vte
ii  libvte-common  0.11.11-5      Terminal emulator widget for GTK+ 2.0 - comm
ii  libvte4        0.11.11-5      Terminal emulator widget for GTK+ 2.0 - runt
acs@delito:~$ dpkg -l | grep gnome-terminal
ii  gnome-terminal 2.9.1-0ubuntu1 The GNOME 2 terminal emulator application

the problem can be reproduced. I will try to test the patch and feedback.
Comment 15 Kjartan Maraas 2005-02-15 11:46:53 UTC
This patch has been used in fedora core for months now. Commiting to CVS.
Comment 16 Olav Vitters 2005-03-04 16:53:03 UTC
*** Bug 169207 has been marked as a duplicate of this bug. ***
Comment 17 adrian 2005-03-07 16:06:43 UTC
The bug is still in FedoraCore3. And the standard update ("yum update" command)
doesn't fix it.

I've reported the bug to redhat's bugzilla:
https://bugzilla.redhat.com/bugzilla/process_bug.cgi#c19

If you have FedoraCore3, the quick fix is:

  rpm --import /usr/share/rhn/RPM-GPG-KEY-fedora-test
  yum --enablerepo=development update vte

That uses the "development" repository and installs vte-0.11.11-15, which seems
to fix the bug.
Comment 18 adrian 2005-03-07 16:11:22 UTC
Sorry, the link was wrong. The link for the bug at redhat is:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100420
Comment 19 Gintautas Miliauskas 2005-09-28 20:10:20 UTC
I can still see this bug in Ubuntu breezy

libvte4 package version: 1:0.11.15-0ubuntu2
gnome-terminal version: 2.12.0-0ubuntu2

I wonder if this has to do with the flickering when I open new terminal windows
or tabs: the white background of the terminal is first clearly painted black and
then a split second later filled with normal white background.  I'd love to see
that flickering go away.
Comment 20 Evert Verhellen 2005-09-28 20:21:20 UTC
A few months ago I have seen to problem again a few times in Fedora Core 4
although I don't recall seeing it lately. These are the package versions that I
have right now (no guarantee that these were the versions when the issue
resurfaced):

vte-0.11.14-3.fc4
gnome-terminal-2.10.0-2
Comment 21 Christian Neumair 2005-09-29 11:14:58 UTC
The rest seems to be a GNOME terminal issue. as the name suggests,
terminal_screen_update_on_realize from GNOME terminal is only called when the
vte widget is realized. This route is also taken for the font updates. I'm using
a white-on-black setup and can confirm that the first few characters on the
terminal slightly flicker, since they're ovbiously set after the first expose
event has happened.
Comment 22 Christian Neumair 2005-09-29 11:15:43 UTC
Reassigning to GNOME terminal.
Comment 23 Olav Vitters 2005-12-29 15:16:15 UTC
*** Bug 317463 has been marked as a duplicate of this bug. ***
Comment 24 Elijah Newren 2006-01-11 05:22:29 UTC
Not a blocker at this stage given the patch that has since been committed that makes the bug much more rare.
Comment 25 bugreports 2006-04-24 21:58:57 UTC
well why actually are we presented a black terminal before it switches its background color to white ?

avoiding this at all would also speed up things....
Comment 26 bugreports 2006-04-29 11:35:41 UTC
one more note: this the window remains black issue, happens not just rarely here... it seems to happen more often especially under load...
Comment 27 Josselin Mouette 2007-01-02 14:09:43 UTC
The Debian bug report about this issue: http://bugzilla.gnome.org/show_bug.cgi?id=125364
Comment 28 Josselin Mouette 2007-01-02 14:10:22 UTC
Hum, this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363612 instead
Comment 29 Mariano Suárez-Alvarez 2007-01-22 10:00:27 UTC
Created attachment 80875 [details] [review]
update the color scheme earlier in the show

I stop getting the background with this patch.

Can you people verify?
Comment 30 Behdad Esfahbod 2007-01-22 19:15:57 UTC
Awesome.  Works here.  Please commit!!
Comment 31 Behdad Esfahbod 2007-01-22 20:29:34 UTC
2007-01-22  Behdad Esfahbod  <behdad@gnome.org>

        Bug 125364 – vte screens are black when initially shown
        Patch from Mariano Suárez-Alvarez

        * src/terminal-screen.c (terminal_screen_reread_profile),
        (update_color_scheme): Update the color scheme earlier in the show.