Version: (using Devel) OS: Linux Installed from: Compiled sources When rightclicking a window titlebar -> shade, the window does not shade at all. Instead it gives some graphical glitch. Without composite this works fine...
actual shading is working, but the window content area is not repainted. You can take the shaded window and move it around to "clear" the area.
only hits opengl backend (dri or not) and opaque windows (i.e. ARGB and translucent windows are not affected) so a hotfix was to check shade state on Scene::Window::isOpaque() (Client* c = dynamic_cast< Client* >( toplevel ); ... && !c->isShade()) but i guess fixing clipping in scene_opengl.cpp would be cleaner :-(
Just used show paint plugin. When the window is shaded the content is painted again. So I don't get it... Idea for a better workaround is to not paint content quads in SceneOpenGL::Window::performPaint() for shaded windows
(In reply to comment #3) > Idea for a better workaround is to not paint content quads in > SceneOpenGL::Window::performPaint() for shaded windows No that doesn't work. Somehow it looks like the window get's repainted before it is shaded.
did you notice that :1445 "if ( ! ((mask & PAINT_DECORATION_ONLY) || client && client->isShaded()) )" break the lower decoration of shaded windows at your side as well? (they seem transparent, shadows are as expected...)
the window area btw remains broken - it never gets cleaned or the window is assumed to be present and the area gets "cleaned" w/ a transparent texture (that's why a translucent window does not show that effect)
d'ohh - error on my side: the issue occurs with render as well (i guess i tested it with the config dialog which happens to be translucent...) so i guess the problem is much rather somewhere in scene.cpp sorry :-(
GOT YA! scene.cpp:236 data.clip = w->isOpaque() ? QRegion(w->clientRect().translated( w->x(), w->y())) : QRegion(); clips away the deco from opaque windows to allow translucent decos, this breaks shading scene.cpp:236 data.clip = w->isOpaque() ? QRegion(w->rect().translated( w->x(), w->y())) : QRegion(); fixes this but breaks translucent decos as toplevel is protected in Scene::Window we need this class to pass the isShade info (i think) so the render chain can query this and handle them like translucent windows (to permit translucent "decos"). is there some freeze on that class or can we manipulate the api?
*** Bug 193853 has been marked as a duplicate of this bug. ***
... or we just fix Client::clientSize() (i.e. set client_size in Client::setShade(), client.cpp ) or adjust Scene::Window::clientRect() question is how critical it will be to adjust the client_size to a null rect in Client::setShade() (why isn't it updated and would updating it cause any other known issues?)
I don't know if it is related, but windows with an own shape create artefacts as well. For example moving kscd creates artefacts or drag&drop a plasmoid from add widgets dialog. In case of kscd changing opacity fixes the issue, that's why I think it could be related. This seems to be a problem since ARGB decos as well and I was able to reproduce in both XRender and OpenGL.
...kscd has a shaped window? did i miss something? (it's not like i'd play CDDAs on a regular base, but i never saw kscd shaped...) but i /can/ confirm it for XEyes... the reason is that obviously a whole rect is assumed to be opaque (there there needed to be a ::clientRegion() or (not by deco) shaped windows need to be handled as ARGB/translucent ones in this function as well) afaics clientRect is only used in the scene painting routine and it's base client_size seems to be set only a few times in geometry.cpp, so it should be safe to return a isNull() rect (Client also provides shape() from Toplevel, so exporting /this/ by Scene::Window and handle them as ARGB should fix this (i'm actually not sure if it would be worth the effort to make a clientRegion() function - these windows tend to be small and handling a complex clipregion on the CPU will likely hurt more than some redundant pixels on the GPU) oh and btw: of course blurring fixes this ;-)
*** Bug 193977 has been marked as a duplicate of this bug. ***
Sometimes the repaint issue occurs elsewhere : - konsole background (set to translucent) - desktop right click - passive loading cursor - ... It occurs now on a new session, but i couldn't reproduce a while back on a session running for some times.
The cases i just reported fall into whats explained at #6. Sorry.
*** Bug 194260 has been marked as a duplicate of this bug. ***
SVN commit 973673 by fredrik: Fix shaded and shaped windows not being clipped correctly. BUG: 193808 M +9 -5 scene.cpp M +1 -1 scene.h WebSVN link: http://websvn.kde.org/?view=rev&revision=973673
*** Bug 194383 has been marked as a duplicate of this bug. ***
This is fixed in 4.3b2, however it may have caused a new problem. Now when shading, any child dialogs are also hidden. This did not happen before.