I can confirm this bug exists on SUSE 9.0 compiled RPMS as well.
I began seeing it's presence in 3.1.94-1 packages.

I use a semi-transparent background set in my schema: transparency 0.77   0   0   0

To correct, I switch to another virtual desktop then switch back to the desktop running konsole and the background repaints itself correctly. This only occurs on inital KDE startup. Any new konsole windows are painted correctly.

Same here. Happens during session restoration if Konsole is on the desktop which is restored. Furthermore it only seems to happen if the first tab was selected on logout. I'll attach a small screenshot.

Created attachment 4376 [details]
Screenshot of Konsole with wrong transparent background after starting KDE

I can confirm the bug on KDE_3_2_BRANCH (as of around 26-01-2004).  What's odd is that if you start the first Konsole, the background is messed up.  If you then immediately start a second Konsole, BOTH backgrounds become correct, not just the one on the second invocation.

Here is some of the relevant output from the first time I ran Konsole.

kio (KLauncher): KLauncher: Got start_service_by_desktop_path('/home/mpyne/kde/
kdeinit: Got EXT_EXEC 'konsole' from launcher.
WARNING: NAME not specified in initial startup message
kio (KLauncher): konsole (pid 18268) up and running.
DCOP: register 'konsole-18268' -> number of clients is now 25
kio (KSycoca): Trying to open ksycoca from /var/tmp/kdecache-mpyne/ksycoca
kdeui (KRootPixmap): [/home/mpyne/kdecvs/kdelibs/kdeui/krootpixmap.cpp:213] act
kdesktop: KBackgroundManager enabling exports.
kdesktop: virtual bool KPixmapServer::x11Event(XEvent*): request for DESKTOP1
kwin: User timestamp, initial:4294967295
kwin: User timestamp, ASN:1360543
kwin: User timestamp, final:1360543
kwin: Activation, compared:1360543:1346470:true

*** Bug 74581 has been marked as a duplicate of this bug. ***

I too experience the bug as above. It is odd that if I log out of KDE, and log back in, the probability of not seeing this bug is much higher than after a reboot.

I can confirm this bug exists on Gentoo, on two different boxes.  Both are running kde 3.2 compiled from souces using gcc 3.3.2.  I have also noticed that I can fix the background just by temporarily maximizing and then restoring the konsole window.

I get this bug since I installed KDE 3.2.0 on my Gentoo. i was looking into bug database and it seems that this bug is very similar with an older one:
  http://bugs.kde.org/show_bug.cgi?id=8624
that is marked as CLOSED.

Bug seems to be a duplicate of Bug 69494 or vice versa.

*** Bug 69494 has been marked as a duplicate of this bug. ***

I have this too on 3.2.1

In my case only the active konsole tab is correct. The other tabs seem
to convert to a tiled transparent background.  Resizing while each tab
is active seems to fix it.

In the my kde 3.2.1 I'm still experiencing the bug specified above setting a transparent background with a dark filter.
Distro is gentoo.
Compiler version is:
 version is gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)

Even though not a blocking bug, quite annoying to be watched... 

Have it on 3.2.2 still *aaarrrggggggggghhhhhhhhhh*

yeah, that makes bugs != RESOLVED

Nobody wants to fix bugs... For example this bug was not still fixed (from kde 3.1) - http://bugs.kde.org/show_bug.cgi?id=63832

Well, Anton, if you were developer, you'd undestand, but you can fix yourself, or pay someone to do it.

CVS commit by giessl: 

Fix #66843.
This is a workaround for a possible bug in KRootPixmap. After resizing
Konsole with multiple sessions and switching to another session, the
tab widget sends resize events, but obviously KRootPixmap isn't able
to handle them correctly.
Please try if it also fixes #71213 and similar.

CCMAIL: 66843-done@bugs.kde.org, 71213@bugs.kde.org, jansen@kde.org


  M +21 -0     konsole.cpp   1.461
  M +1 -0      konsole.h   1.177


--- kdebase/konsole/konsole/konsole.cpp  #1.460:1.461
@@ -881,4 +881,5 @@ void Konsole::makeTabWidget()
 {
   tabwidget = new KTabWidget(this);
+  tabwidget->installEventFilter(this);
   tabwidget->setTabReorderingEnabled(true);
   if (n_tabbar==TabTop)
@@ -943,4 +944,19 @@ bool Konsole::eventFilter( QObject *o, Q
     }
   }
+  else if (o == tabwidget)
+  {
+    // There is probably a bug in KRootPixmap which makes this workaround
+    // neccesary:
+    // Mark the background of invisible TEWidgets dirty so they can be
+    // repainted when they are displayed next.
+    if (tabwidget && ev->type() == QEvent::Resize) {
+      for(int i = 0; i < tabwidget->count(); i++) {
+        QWidget *page = tabwidget->page(i);
+        if (page != tabwidget->currentPage()) {
+          rootxpmsDirty[page] = true;
+        }
+      }
+    }
+  }
   return KMainWindow::eventFilter(o, ev);
 }
@@ -2426,4 +2442,9 @@ void Konsole::activateSession(QWidget* w
   activateSession(tabwidget->indexOf(w));
   w->setFocus();
+  if( rootxpmsDirty[w] ) {
+    // force repaint!
+    rootxpms[w]->repaint(true);
+    rootxpmsDirty.remove(w);
+  }
 }
 

--- kdebase/konsole/konsole/konsole.h  #1.176:1.177
@@ -285,4 +285,5 @@ private:
 
   QPtrDict<KRootPixmap> rootxpms;
+  QMap<QWidget*, bool>  rootxpmsDirty;
   KWinModule*    kWinModule;
 

This bug is still present in kde 3.2.2, as packaged in Fedora Core 2 (including the update to kdelibs)

I haven't tried the patch from Sandro Giessl; re-compiling kde is a bit of work. You don't happen to have a compiled konsole binary which would happily
talk to the kdelibs in FC2 ?

The patch seemed to work for me (I'm running KDE CVS), but you can still see the degradation of the background at first for about a half-second which is distracting. :-(

Should be fixed now for KDE 3.2.3. If you want to test, make sure to update both kdelibs/kdeui and kdebase/konsole (CVS HEAD or KDE_3_2_BRANCH)

Sandro: I reverted your patch and fixed it in KSharedPixmap/KRootPixmap instead, hope you don't mind.

Hi, I solved this bug some days ago, but here is what I discovered:

When starting konsole, a TE widget is added on a QTabWidget that is the main windget of the konsole. Of course all is hidden, so the TAB has its minimum size( 120x75 pixels if I remember good). At this time (with the konsole widget at the right size, but the TE widget at 120x75 pix) the KRootPixmap builds the 'small chunk of background' you see tiled in background.

By fixing this (for example by propagating the right sizes to child widgets when the konsole is hidden) another problem raises: *extreme high memory consumption* and *slowlyness*.

I saw that 10 konsole tabs had 10 KRootPixmap buffers (and I run in 1400x1024)! So I let you guess the memory usage. The problem also raises when switching between tabs, it seems *so slow* (directly proportional to open konsole tabs).

I have no checked the patch by Waldo yet (a great well coded patch for sure! :-) and I hope it fixes also the performance issues.
Or else we can form a working group to rewrite some gui stuff on konsole so we can optimize it (seems like a bit hacked-up stuff now.., isn't it?).

Performance problems will be solved by using real transparency provided by the X.org Kdrive X-server.

KRootPixmap is one big fat hack and I would like to see it go sooner rather than later.

But one does _not_ want real transparency for konsole; imagine two
konsoles on top of each other: if the text of the konsole below appears
(even faded) in the konsole above, you won't be able to read anything.
The visual aspect of the present solution is much nicer than real
transparency.

Note that this bug has indeed disappeared with kde-3.2.3, but now I have
another (probably related) problem which appeared with this new.

From time to time (not very often), the konsole would pop up completely transparent (you just see the frame and the background image. In my normal colour scheme, the background image is blent with some white in order to decrease the contrast. When the bug occurs, the background is displayed with its real colours) and the text you try to type is black on a black baground (in other words, some small black rectangles appear instead of letters.)

The occurence is rare, but when that happens, it happens several times in a row. The only thing you can do is to open and close new konsoles till one
pops up normal.

> But one does _not_ want real transparency for konsole;

Indeed, you do want real transparency.  The text itself is not drawn transparent, just the background (think of how Mac OS X does their transparent terminal).

The hack we have in place now means that you *can't* see one Konsole through another, so you already can't read anything in the background.

And I can't reproduce your bug, but you should probably open up a separate bug report instead of hijacking your old one. :-)