Running KDE trunk with the new Air theme, tooltips leave a rectangle instead of disappearing when the mouse stops being over it. See attached screenshot. Reproducible: Always Steps to Reproduce: 1. Install the new Air theme by updating git 2. Show tooltips as in default settings 3. Hover with the mouse on an app in the task manager 4. Tooltip appears 5. Leave the tooltip with the mouse Actual Results: A rectangle stays Expected Results: Nothing should be left graphically, the tooltip should disappear. I can have several such rectangles. Not reproducible with other themes
Created attachment 75780 [details] The rectangle that stays after leaving the tooltip
Probably something related to the fact now all Plasma elements use KWin to render the shadow around it?
this started happening here with kde 4.10 rc1 on ArchLinux packages.
This only happens when the tooltip disappears without the mouse pointer over it. If I keep my mouse over the tooltip and let it disappear normally, no ghost rectangle remains.
(In reply to comment #2) > Probably something related to the fact now all Plasma elements use KWin to > render the shadow around it? looks like it because giving another window focus makes the ghost rectangle disappear.
ahh - theme version driven: what carries that air theme? kde-artwork? Most likely bug #312168
Git commit d12312f25550283581c2693235e4d8890fe96882 by Weng Xuetian. Committed on 26/12/2012 at 17:28. Pushed by xuetianweng into branch 'KDE/4.10'. fix tooltip shadow problem. avoid confusations between the deleted window size and the "dirty" area. REVIEW: 107905 M +1 -1 plasma/tooltipmanager.cpp http://commits.kde.org/kdelibs/d12312f25550283581c2693235e4d8890fe96882
Looks fixed to me. Thank you!
This should btw. not happen regardless - does the "shadow->removeWindow()" call sync the X server?
(In reply to comment #9) > This should btw. not happen regardless - does the "shadow->removeWindow()" > call sync the X server? seems no explicit call to XSync
please try reverting the fix (just locally - current order is more sane anyway) and XSync(dpy, False) before closing the window. If that works, we'll have to figure whether the case can be hardened in kwin (reg. carrying over dirty regions from the client to the deleted)
(In reply to comment #11) > please try reverting the fix (just locally - current order is more sane > anyway) and XSync(dpy, False) before closing the window. > If that works, we'll have to figure whether the case can be hardened in kwin > (reg. carrying over dirty regions from the client to the deleted) shadow->removeWindow(tipWidget); XSync(QX11Info::display(), 0); tipWidget->hide(); Will reproduce this bug.
*** Bug 312257 has been marked as a duplicate of this bug. ***
*** Bug 312264 has been marked as a duplicate of this bug. ***
*** Bug 312503 has been marked as a duplicate of this bug. ***
*** Bug 312612 has been marked as a duplicate of this bug. ***
Although this is very rare now I still see those rectangles sometimes. http://www.psw.ro/download/rectangles-intel-kde410.mkv This is on Arch Linux X64 and KDE 4.10. * VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) * xf86-video-intel 2.21.0-1 * intel-dri 9.0.2-1 * xorg-server 1.13.2-1 * mesa 9.0.2-1
I see it quite frequently actually. if I click twice on the clock to show and then hide the calendar, with ca 33% chance a portion of the shadow remains visible. Using KWin + compositing (on a intel GM45), happens both with OpenGL and XRenderer compositing. kde-workspace-4.10.0-10.fc19.x86_64
Appears to be a race condition. When selecting "Very Fast" as Animation speed in the desktop effects configuration, the issue is reproducible with probability > 50%. When selecting "Instant" or "Normal" on the other hand, the issue never appears. This issue persists with kde-workspace-4.10.1-1.fc19.x86_64.
I can confirm Sandro Mani's report. I get this every time when using an auto-hide panel and selecting 'very fast'. Tested on Archlinux 4.10.3, 4.10.2 Intel, Nvidia Proprietary, OpenGL, Xrender.