With the new Air theme the shadows around Plasma popups are not rendered while they are sliding in or out
Steps to Reproduce:
1. Use new Air theme in KDE 4.10 RC1
2. Click eg. battery monitor or NM applet
Shadow is only drawn when the sliding animation is done, not while it is animating
Shadow is drawn (like Blur) during the entire animation
Maybe KWin issue?
I guess it's a KWin issue. Seems that KWin clips the popup texture while transitioning. The shadow above the popup is rendered (until it gets outside the clipping box at the end of the animation) while the shadow on the sides is not during the transition
Not here - regardless of blur, backend (except gles not tested) "SlidingPopups" or "GenericAnimations"
We had similar (hit the tabbox shadows) but that should be fixed (code suggests that)
Can you share your supportInformation?
Compiled from sources?
Reproduceable on both 4.10 RC1 as well as today's master. Only visible with SlidingPopups enabled, without works fine but then the dialog either zooms in or fades in, doesn't slide, of course.
Benutzen Sie die folgenden Informationen, wenn Sie nach Unterstützung fragen, z. B. auf http://forum.kde.org.
Sie enthalten Informationen über die momentan laufende Instanz, welche Optionen verwendet werden,
welcher OpenGL-Treiber verwendet wird und welche Effekte laufen.
Bitte geben Sie die untenstehenden Informationen bei einem Pastebin-Dienst wie http://paste.kde.org ein, anstatt sie direkt in die Hilfediskussionen zu schreiben.
Qt Graphics System: raster
Compositing is active
Compositing Type: OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL version string: 3.0 Mesa 9.1-devel
GPU class: IvyBridge
OpenGL version: 3.0
Mesa version: 9.1
X server version: 1.13
Linux kernel version: 3.5
Direct rendering: yes
Requires strict binding: no
GLSL shaders: yes
Texture NPOT support: yes
Virtual Machine: no
OpenGL 2 Shaders are used
Currently Active Effects:
Before i punish myself: do you happen to know whether it also wobbles?
Doesn't wobble when sliding in/out, only wobbles when I manually move it using Alt+Click (which shouldn't move the window in the first place)
Using the "Color redraw areas" effect, you can see that there actually is some border/shadow supposed to be drawn outside the popup - there is a 20px area that is redrawn but for no visible reason
As far as I can tell there are other parts of the Plasma theme affected by this wrong clipping/redrawing area as well:
- Panelcontroller has shadow on both sides
- On Screen Displays (volume change, brightness change) has no shadow at all
- Tooltips sometimes leave ghostshadows behind when they disappear
(In reply to comment #6)
> Using the "Color redraw areas"
"Show repaint" =)
I somewhen have to install the i18n package ;-)
> some border/shadow supposed to be drawn outside the popup - there is a 20px
> area that is redrawn but for no visible reason
could be for blurring / wobbling - try deactivating both effects.
Does this also happen with the xrender backend?
(or tell me which git repo contains the "new" air theme ;-)
> As far as I can tell there are other parts of the Plasma theme affected by
> this wrong clipping/redrawing area as well:
> - Panelcontroller has shadow on both sides
I guess it's supposed to have them on only one (far edge from the panel)?
-> plasma bug, make better shadow pixmaps or offsets (or keep the controller under the panel, XRestackWindows, since it's likely unmanaged)
> - On Screen Displays (volume change, brightness change) has no shadow at all
Do they have alpha at all? (see bug #311995)
> - Tooltips sometimes leave ghostshadows behind when they disappear
Should be resolved. Execution order in plasma, maybe missing X11 sync and/or insufficient damage robustness in kwin
(In reply to comment #7)
> Does this also happen with the xrender backend?
Also happens with XRender
> (or tell me which git repo contains the "new" air theme ;-)
I just got it alongside with the upgrade to KDE 4.10 RC1.
It lives in: [kde-runtime] desktoptheme/air
(I have no idea who came up with that "system" in where the artwork lives, some is on SVN kde-artwork, some in kde-baseartwork, some is directly in the app using it …)
> I guess it's supposed to have them on only one (far edge from the panel)?
> -> plasma bug, make better shadow pixmaps or offsets (or keep the controller
> under the panel, XRestackWindows, since it's likely unmanaged)
Right. So, theme issue or new shadow system issue. Stacking under would not work since then you would have the panel shadow above the panelcontroller
> Do they have alpha at all? (see bug #311995)
Is has alpha, it looks normal (transparency with blur) just without the shadow, so you can eg. hardly see it when in front of a white webpage
same here. the OSD volume has no shadow. This worked in 4.9.x
Sorry for spamming but plasma panel/etc.. looked beautiful in 4.9.x so why were there changes to the theme?
(In reply to comment #8)
> > Do they have alpha at all? (see bug #311995)
> Is has alpha, it looks normal (transparency with blur) just without the
> shadow, so you can eg. hardly see it when in front of a white webpage
Random guess here would be that the shadow is set before the ARGB hint (what causes Qt to create a new window, lacking all properties of the original one) - adding, withdrawing and altering shadows works reliably on eg. the bespin decoration since i don't know when.
Now that KWin renders shadows for Plasma, I suspect the
in the brightnessosdwidget to be the cauae
nope, that's actually a no-op from KWin point of view. The method sets the property "_KDE_SHADOW_OVERRIDE", but searching for it in KWin src folder returns 0 results. I think it used to be used in the old shadow effect.
(In reply to comment #12)
> I think it used to be used in the old shadow effect.
Also that would not explain why it's there later one, resp. (even more strange) why it's there, but clipped (in either XRender AND OpenGL which use totally different clipping) while the repaint area seems to be right.
Compiled and installed "new" theme btw., but there's no difference (and the panels etc. don't have a shadow hint - maybe this was added to libplasma *very* recently?)
You mean using KWin for Plasma shadows? It's just a few weeks old:
Hmm, maybe we need to manually add a DialogShadow on the brightnessosdwidget now but I couldn't get it to dork (the dialogshadows thing is private)
Just noticed that the Brightness OSD has no transparence whatsoever, it seems when it is launched (PowerDevil daemon) the compositor is not fully up and it seems to not notice when it is and so the Brightness OSD is in its non-composited state (ie. fully opaque, no shadow). The KMix OSD, however, is transparent with blur behind but also lacks a shadow. Really weird.
But was already broken in 4.10 Beta 2 with the old Air theme.
reg. absent ARGB, see https://git.reviewboard.kde.org/r/107983/
but i still cannot reproduce clipped shadows here (while they have a kwin shadow property) regardless of all kwin settings.
now trying plasma conditions - you use the raster graphicssystem and glib dispatcher, i assume?
Adding Aaron and Marco to CC as it's another shadow related regression
(In reply to comment #12)
> nope, that's actually a no-op from KWin point of view. The method sets the
> property "_KDE_SHADOW_OVERRIDE", but searching for it in KWin src folder
> returns 0 results. I think it used to be used in the old shadow effect.
interesting. this means we can remove it in libplasma2 then ...
Yes, this has been the case from the moment we started using kwin's window shadow support. It is some sort of interaction with the slide in effect. Apparently the shadow does not get applied until the window is fully slid in or out.
as far as I can see the shadow is applied but clipped at the sides. When you set animation speed to very slow, you can see that the shadow at the top of the popup (in case it emerging from a bottom panel) is drawn. I did a screencast but accidentally attached it to the wrong bug report.
(In reply to comment #21)
> accidentally attached it to the wrong bug report.
Being where? ;-)
It's obvious why it is broken. From the code:
region = QRegion(w->x() + splitPoint, w->y(), w->width() - splitPoint, w->height());
region in the clip region to which the rendering is restricted. x(), y(), width() and height() are the geometry of the window. When the shadow used to be part of the window that worked. Now it is no longer part of the window and the shadow gets clipped away.
i could have simply put shadows under yakuake m(
works "nearly" with generic animations, but the source edge must not be clipped by the visualRect but geometry.
Git commit e448aeb49efb031d93ce3fcefcca9c01fb920697 by Martin Gräßlin.
Committed on 08/01/2013 at 09:19.
Pushed by graesslin into branch 'KDE/4.10'.
Do not clip away shadows in SlidingPopupsEffect
Animation now completely based on the expandedGeometry which includes the
shadows and another repaint at the end of the animation is added to
ensure that there are no leftover shadows.
M +19 -16 kwin/effects/slidingpopups/slidingpopups.cpp