Posted on by Martin Flöser

New KWin Shadows

One of the features which got killed in the process of porting KWin’s Compositor to OpenGL ES was the Shadow effect. For some time already the Shadow effect was not on the level we expect from our components. The code had become too complex to maintain and the port to OpenGL ES would not have been trivial. So the port was a good point to step back and think about what we actually need in the Shadow effect.

For quite some time we have an improved shadow system which allows the window decoration to provide the Shadow for decorated windows. This is used by e.g. Oxygen, QtCurve and Aurorae. So most windows already have a very advanced and good looking shadow. The Shadow effect itself is only used for so-called unmanaged windows such as menus or drop-down lists and for “legacy” window decorations such as Plastik.
The obvious disadvantage is that menus have a different shadow than all other windows. This means the designers do not have control over the shadows. But shadows are an important part of the design. A shadow should follow the widget style’s light model and by that one shadow to rule them all is just not possible.
Since I started to consider dropping the Shadow effect I have been in contact with mostly Hugo from Oxygen fame to gather the requirements for a new Shadow system. After long and fruitful discussions also including members from other Widget Styles and Compiz we designed a new system. Hugo recently implemented the Oxygen part and this weekend I implemented the first OpenGL version of the new system:
The main difference to the old system is that the Shadow is no longer an effect but moved directly into the Compositor. This follows the approach of the Decoration Shadows which are also directly in the Compositor. By moving the Shadow into the Compositor we can better control and optimize the rendering process. The compositor itself knows about the existence of the Shadow and can update the correct screen areas. As the shadow is rendered together with window it follows automatically opacity or transformations like wobbling.
A nice addition of the new Shadow system is that it is completely controlled by the to be rendered window which allows to use it also for Plasma elements such as the Panel shadow or in KRunner (yeah no more clickable Shadow). What could also be very nice is to use it for shaped windows. Up to now windows with custom shape could not get a Shadow as our effect just could not know if it looks good in the end. The window itself knows its shape and can provide a shadow adjusted for the window. So maybe Yakuake will soon have a Shadow 🙂
If someone wants to test it, you can build the kwin/oxygen-shadows branches in kdelibs and kde-workspace. There is still some work to be done like the XRender implementation, some optimizations and currently “normal” windows are not yet supported. Also we would like to have some fallback for windows not useing either Oxygen decoration or widget style.
I hope that we can bring our system as an addition to the EWMH specification. The system has been designed to not be KWin or KDE specific and it’s a usecase actually required in all Desktop Shells.

=-=-=-=-=
Powered by Blogilo

22 Replies to “New KWin Shadows”

  3. Great! Hopefully this will fix the issues with shadow compatibility. Out of curiosity, does the new shadow system take into account the z-order of windows?

    1. Out of curiosity, does the new shadow system take into account the z-order of windows?

      No, the primary use case for the new shadow system are unmanaged windows which are always topmost in the stacking order.

  5. Okay. Shadows. Instead of fixing the errors and lags and KDE you adds new shadow system. WOOHOO. Bravo.

    No, seriously, I’m outta here.

    1. Any idea how many bugs and performance lags the new shadow system solves? Any idea why I spent time on implementing it?

    2. Given your demonstration of sheer ignorance, it’s any wonder you were here at all. Don’t worry: you won’t be missed.

  6. I don’t understand something, when will this new shadow system be used, and when will widget draw their own shadows?
    With this new system, will oxygen for example draw shadows of the menus and “unmanaged windows”?, if not what does this new system fix?

    1. The new system gives control to the widget style (in most cases Oxygen) to define the shadow instead using a generic one. Hope this answers the question

      1. I still don’t understand something, in this new system which shadow is used for menues and unmanaged windows? generic or widget style?

        1. Under the new shadow system, there is no, “generic” shadow. If the application doesn’t define shadows, it doesn’t draw them.

        2. Just wondering: does this leave open the possibility of translucent shadows? That’s been my biggest gripe of oxygen-shadows so far.

          2. Semi-transparent – “see through”. Right now, they’re big black blocks, which you can see by increasing their size.

            1. yes the shadow has an alpha channel, so it depends completely on Oxygen and the shadows they pass to KWin.

  7. Also, these “menu buttons” should be standard in every app, and put into the list of possible buttons when customizing the toolbar (no talking about defaults)

Comments are closed.