Version: 3.4 beta 2 (using KDE KDE 3.3.92) Installed from: Unlisted Binary Package OS: Linux KDE 3.4 beta 2 Composite extension: enabled Fade in windows (including popups): UNchecked Fade between opacity changes: UNchecked Testcase: 0. get 2 empty desktops: #1, #2 1. #1 - start Konqueror - make it big (maximized if you want) 2. #1 - start KWrite - make it big (maximized if you want) now KWrite should be "over" Konqueror. 3. switch to #2 (which is empty, to prevent another translucency bug) 4. switch to #1 You will notice: a) Konqueror appears first with the oppacity of an inactive window (which is correct, bug BUG: it shouldn't repaint, the flicker looks terrible especially if you're working with 2 fullscreen applications) b) KWrite appears afterwards ok (correct opacity) over Konqueror Note that: - it doesn't matter if the apps are maximized or not (the bug is easily noticeable on apps occupying a lot of space on the desktop) - IMO, it might not be a bug in the translucency code, but in the desktop switching code: repaints might be unnoticeable because they're fast when translucency is not involved)
i assume what you notice is (???): 4.: konqi maps active, then falls inactive and kwrite is mapped active?? if not: what do you mean by "it shouldn't repaint" - it must be mapped (as it has been there when you left the desktop) and therefore is of course shown
Re-analysis: A) Changed environment: 1. remove background picture + set background color to some "screaming" color, like green(0,255,0) 2. enable "Fade between opacity changes" (helps by slowing down the "flicker" - which will turn out not to be a flicker) 3. Move both fade-in/out cursors to the left to make opacity transitions as slow as possible. B) Testcase + effect 0. get 2 empty desktops: #1, #2 1. #1 - start KWrite - make it big (maximized if you want) 2. switch to #2 (which is empty, to prevent another translucency bug) => KWrite will start fading out, remaining active, even if it's the active application on Desktop #1 (=will get the opacity of an inactive window, while being active) 3. !!!! now, you can switch to #1 in 2 situations a) while KWrite is fading out. Making #1 the current desktop won't stop KWrite from fading out -> there you have http://bugs.kde.org/show_bug.cgi?id=99805 b) after KWrite finished fading out: you'll get the "flicker", if the fade-in time is really short IMO, active application on any desktop should now get inactive opacity when the desktop is switched. I've created bug http://bugs.kde.org/show_bug.cgi?id=99921 on fading on desktop change.
Correction: old: active application on any desktop should now get inactive opacity new: active application on any desktop should NOT get inactive opacity
Does this problem still exist in a recent KDE version?
Yes, this still happens with KDE 3.5.4. To make the bug reproduction faster: 1. make the fade in/out transitions as slow as possible. 2. make make the opacity difference between active and inactive windows big >50% 3. set desktop #1 background color to Dark Blue. 4. start ONLY KWrite MAXIMIZED on desktop #1 (KWrite with a bright document background, white or something - the contrast between the app and the desktop makes the problem more obvious) 5. move to desktop #2 6. move back to desktop #1 You'll notice that, even if KWrite was the only active application on desktop #1, it changes opacity from inactive to active. This gives a strange flickering effect if there are many apps stacked one over another, with different opacity levels. When switching from desktop #2 to #1, the apps on #1 should set their opacity statically, without any fading (fading should be disabled temporarily). The bug might actually NOT be in the opacity code, but in KWin's code which handles active/inactive windows, but I'm not really sure. Hope this helps. Mircea
Maybe this (http://bugs.kde.org/show_bug.cgi?id=99921) should be implemented instead of fading all the windows.
KDE4 will include compositing support in KWin instead of Kompmgr and I don't expect this problem to be fixed for KDE3 by now, sorry. Closing.