| Summary: | window shadow not always fully painted | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | S. Christian Collins <s_chriscollins> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | b7.10110111 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | screenshot of shadow glitch | ||
|
Description
S. Christian Collins
2009-07-26 23:38:30 UTC
Created attachment 35655 [details]
screenshot of shadow glitch
I forgot to mention, I'm also running: Kernel: 2.6.30-020630-generic KDE: 4.3 RC3 NVIDIA driver: 185.18.14 just to be sure - can you reproduce this with any deco that's /not/ oxygen/ozone/nitrogen? Other deco's no longer exhibit a shadow as of 4.3 RC3. I've also noticed that if a window deco (besides ozone/oxygen) has rounded corners, the corners are no longer transparent with compositing enabled. They look fine with compositing disabled... should I file that as a separate bug? (In reply to comment #4) > Other deco's no longer exhibit a shadow as of 4.3 RC3. Do you have the shadow plugin activated? > I've also noticed that if a window deco (besides ozone/oxygen) has rounded corners, the corners are no longer transparent with compositing enabled. They look fine with compositing disabled... should I file that as a separate bug? Which decos did you try? (decorator and another 3rd party had "bugs" regarding this) And in case: yes - that'd be different bugs (with differend assignees - supposing it doesn't hit /all/ decos) According to information posted in bug 198704 <https://bugs.kde.org/show_bug.cgi?id=198704>, the shadow plugin no longer controls window shadows--that is up to the window decorator I guess. This change is probably what has contributed to the emergence of the bugs I am experiencing. FYI, Dekorator and Plastik were the decos with rounded corners that I tried. Both of those decos worked fine up until recently (sometime within the last two RC releases). (In reply to comment #6) > According to information posted in bug 198704 > <https://bugs.kde.org/show_bug.cgi?id=198704>, the shadow plugin no longer this /only/ holds for decos that support a specific attribute what's (atm) oxygen (and it's derivates) only + plus some decos that do "accidently" all other decos still rely on the shadow plugin (just like popup menus, combobox lists, undecorated windows, etc.) > FYI, Dekorator and Plastik were the decos with rounded corners that I tried. > Both of those decos worked fine up until recently (sometime within the last two RC releases). plastik works for me. can you try web/keramik and in case you have: qtcurve/bespin/aurorae? Never mind. Plastik works for me as well. I don't know what I was doing when I checked it earlier... Anyway, looks like deKorator is the only deco causing problems at the moment. Sorry about the confusion. Christian, deKorator problem is bug 200311. Looks like the deKorator developer(s) have fixed the issue as of version 0.4.0.3 (http://www.kde-look.org/content/show.php/deKorator?content=87921). Anyway, sorry for leading things off topic here and distracting the focus from the actual bug. I've discovered more helpful details about this bug: 1) The problem only occurs with the Oxygen/Ozone window decorations (and probably any others that specify their own shadows). Other window decorations (such as Plastik), that have their shadows drawn by the shadow plugin are unaffected by this bug. 2) The fade plugin must be enabled 3) although it's harder to get a window to appear with the shadow entirely missing in spots, it is quite common to see areas of the shadow that are less than 100% strength--if you look closely around the shadow it will often appear "spotty", where there are patches of 100%, 60%, etc. shadow strength. SVN commit 1004121 by graesslin: Reimplement addRepaintFull() in Client and add the padding to the repaint region. CCBUG: 201596 M +1 -0 client.h M +6 -0 composite.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1004121 If possible please try with that commit. I'm not totally sure if it fixes the issue - it is hard to test. Unfortunatelly I can't just backport the patch as it needs changes introduced by fixing bug #201780 (which isn't backported yet) SVN commit 1013298 by graesslin: Backport rev 1004121: Reimplement addRepaintFull() in Client and add the padding to the repaint region. CCBUG: 201596 M +1 -0 client.h M +6 -0 composite.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1013298 Assuming the commits fixed the problem - if anybody is able to reproduce in 4.3.1 please reopen This bug (at least with the same symptoms) appears in kde 4.8.3. Now it appears not on decorated windows, but on tooltips, so I'm not sure if this is the same bug or I should file a new one. See this screenshot: http://i.imgur.com/HYP0H.png How to reproduce (KDE 4.8.3 on 64 bit ubuntu 12.04 LTS): 1. Start systemsettings 2. Highlight Quit button 3. Move mouse cursor to Help button fast enough that the tooltip doesn't disappear 4. Tooltip jumps to another position on screen and gets another text&size 5. After moving cursor from one button to another several times you can notice the glitch. This is true for . On another machine (32 bit LFS with KDE 4.8.2) I can't reproduce it this way, but I can another way: 1. Start dolphin 2. Undock Places panel 3. Steal focus from Dolphin main window so that Places panel disappears 4. Activate Dolphin window 5. The panel appears and its shadow is only painted where main window shadow is visible |
