Posted on by Martin Flöser

What we did in KWin 4.11

With the release of the 4.11 Beta 1 behind us it’s a good moment to look back on this last half year on development. KWin 4.11 is a very important release for us. As you might have heard at the last Plasma sprint we decided to make 4.11 the last release of the KDE workspaces based on Qt 4. Fear not: the KDE Software Compilation with all it’s great application will see a 4.12 release – at least I have not heard anything else, just the workspaces need some time to do the Qt 5 transition. In addition we want to provide extended bug fix releases for the 4.11 release of the workspaces. So 4.11 is a very important release – being the bridge towards Qt 5.

This is clearly what dominated the development of this release cycle. While porting to Qt 5 is easy in 99 % of the cases, KWin hits the 1 remaining per cent. There are many non-portable X11 specific features in Qt 4 and sometimes I think we used them all and all of them got removed in Qt 5. That’s not a bad thing – in fact I think it’s a good thing. I don’t want to go into detail about the problems we hit and why we used these Qt features in the first place – if you are interested come to my Akademy talk.

In many cases the changes in Qt required to rethink the problem. A good example is that a QPixmap no longer references an XPixmap which we heavily used during rendering the window decorations. This was causing us quite some performance problems with the combination of Qt graphics system raster and the XRender compositor. At the moment I’m running this combination without any noticeable performance difference thanks to the restructuring forced by preparing for Qt 5. Also in the OpenGL case the decoration rendering got quite improved thanks to Fredrik forcing me to improve the proposed changes and also doing some further changes.

Speaking on performance improvements: Fredrik reworked our OpenGL 2 compositor code base and also introduced a new OpenGL 3.1 code path. By default we still use OpenGL 2 with the fallback to OpenGL 1, but one can easily switch. If the hardware doesn’t support OpenGL 3.1 it automatically falls back to OpenGL 2 or OpenGL 1. When running kwin_gles we default to OpenGL ES 3.0 if present otherwise OpenGL ES 2.0 is used.

But that’s not the only change done to the OpenGL compositor. Thomas and Ralf worked on improving our v-sync behavior. There are now multiple strategies one can choose from – this should help to serve all use cases and setups in a better way. Buffer age support has not made it for 4.11 yet, but I’m quite confident that this will end up in the next release.

One of the tasks we continued from 4.10 is the porting to XCB. This also forced us to rethink some of our code. One of the areas which got rewritten because of this is the screen edge handling. It’s now finally multi-screen aware, but still only the four real corners can be configured, corners between screens don’t make much sense. And here with the screen edges we have one of the few user visible changes in KWin: a highlight when approaching the edge. So this hidden feature is finally no longer hidden.

Another small visual change is concerning the outline when using quick tiling/maximizing on screen edges. The outline should now better indicate what area will be covered by the window. Also based on common feedback the moved window is put above the outline. This used to cause problems with dark Plasma themes causing.

The last changes I want to mention are some effects rewritten in JavaScript. This is mostly to improve the maintainability of the code. The JavaScript effect API is optimized for animating windows based on state changes. If I remember correctly the rewritten effects are Dialog Parent, Login, ScaleIn and Translucency. Thanks to Kai Uwe for helping us with these tasks. There are still a lot of effects which would benefit from this work. So get your editor ready 😉

Overall the effects have seen some changes. BoxSwitch effect got finally the kick as the functionality is now completely available in the QML Window Switching functionality. Explosion got the kick as it has been unmaintained and broken for a long time. The Outline is no longer implemented as an effect, but moved back into KWin core. The add/remove desktop button in Desktop Grid and the close window button in Present Windows got reworked with QML and Plasma components – another nice improvement thanks to Qt 5. Present Windows has also an unpopular change: the mouse action for closing a window got removed. But also we have the code ready to rewrite Present Windows and Desktop Grid with QML (a task for next version). The Maximize window effect got a nice improvement in the OpenGL compositor: it cross fades with the previous window texture which removes the up/down scaling which was not looking that nice. Thanks to Aurelien for writing software exposing bugs in KWin which require reworks allowing to implement this feature.

I’m quite sure that I have forgotten to mention many really important changes which we did over the last half year. It’s a long time and after all we changed 666 files with 32516 insertions and 29217 deletions (git diff –shortstat v4.10.0..master — kwin (master being 4a172a9d)) including the changes by scripty.

52 Replies to “What we did in KWin 4.11”

  2. I must say that this release has been one of the best things in a long time. The “Full screen repaints” option finally fixed my tearing issue on NVIDIA Quadro 1000M graphics card with video players (other than uncomposited SMPlayer+VPDAU) that I have been suffering from almost two years (tried pretty much everything I could find from the internet, reported the issue to NVIDIA etc). The feature loss in Present Windows was unfortunate but oh well.

    What benefits does OpenGL 3.1 bring? I have it enable and everything works smoothly; I’m not sure if there’s any difference though.

    Thanks.

    1. Presumably it’s the core profile in GL 3.1.

      If so, I know the Mesa Intel devs have said that will provide better performance/less memory usage with their driver. Probably other Mesa drivers too, but not proprietary ones.

      It’s also probably a lot closer to the GLES 2/3 code which may increase maintainability over the long run.

  3. If this fixes the tearing I’ve experienced with my nvidia card for ages i want it now, but i dont know how

    1. Apart from building it yourself it depends on the distribution you are using to get binary packages.
      Kubuntu has project neon to get trunk builds to test.
      Opensuse does also provide repositories containing weekly snapshots of KDE master.
      Be careful though, as this stuff is only for testing purposes.

  4. Thanks for this blog entry and all the others where you explain in an interesting way the details of what is going on in Kwin. I have to admit that from a user perspective the things you work on are seemingly boring. Basically I am just happy if window handling work and are not slow. But the way you write it up, makes all of it interesting after all. Keep up with your good work and thanks!

  6. “resent Windows has also an unpopular change: the mouse action for closing a window got removed. ”

    Thank you for telling us this. Usually, people exclude / brush over this stuff in hopes that people won’t notice (and then, of course they do). It isn’t a big deal for me, but in a way, it makes the whole thing more trustworthy that you keep us in the loop with this.

    Thanks for all your hard work as always!

    1. Unfortunately people have been added to the loop a bit late, see the discussion at https://bugs.kde.org/show_bug.cgi?id=321190 and https://bugs.kde.org/show_bug.cgi?id=321252.

      This should change in the future according to a comment though, I hope it will.

      Also: yay, I assume I am one of the people who are to blame for mentioning it as unpopular 😉 I am pondering to rename it locally in my revert patch, something like “Martin’s hidden function”

      However: yes, thanks for the great work Martin. So far I didn’t find any regressions, and the things I use most seem to work fine. I don’t see a performance increase, but I was happy with performance before anyway (binary nvidia driver).

      What I really love is that transparency now has an animation, which not only makes it look nice, but also prevents artifacts which the effect sometimes had in the past (I assume that nvidia did the redrawing at the wrong point, since only half of the transparency was set. It was corrected when the window had to redraw itself)

  7. I like that you also mentioned the other contributors.
    Cause some people think that you are the only maintainer 🙂

  8. Thanks for your efforts and the efforts of the team, they’re greatly appreciated by a large, large amount of people. Keep it up!!

  9. Thank you for your work!
    I have a strange behavior of screen edge effects, such as desktop grid or dragging a window to another desktop. All these effects work only if the delay is less than 250 ms. It seems that the behavior has changed.

  10. 1. The “Re-use screen content” flag, with Game Mode, is doing wonders here. I can idle at less than 1% of CPU with Lanczos, and with no tearing. Every KWin release has been a massive improvement over the last one, and this is no exception.

    2. Is it possible to combine “Desktop Cube” and “Cube Animation”, and, if possible, to apply the QML treatment to them?

      1. I bet he’d like to see those two effects combined in one (To be honest, I don’t get the divide too) and written in QML

  11. Hi,

    Great work as always. There is one sentence I don’t understand though:
    “Present Windows has also an unpopular change: the mouse action for closing a window got removed.”
    I am using a trunk build of KDE 4.11 (project neon for Kubuntu) and I can still see buttons appearing for closing windows in the present window effect. This will be removed? And if so, why?

    Thank you very much!

  12. “It’s now finally multi-screen aware”

    Good gravy! Can you elaborate on what this means people users with more then one monitor?

    1. If you are a multi-screen user it means that the implementation now considers the actual screen geometry and not the virtual combined geometry of all screens.

  13. Do the screen edge changes mean that when I plug in an extra monitor, my right edge panel automatically moves to the “real” right edge? If so, yay!

  14. Thanks for the Kwin team for all this good work!

    With KDE 4.9, Kwin gets 60 fps with my Intel integrated graphic and 70 fps with my Amd dedicated card (catalyst driver). Currently with this configuration, the Amd card doesn’t work with vsync, so it’s really great Kwin adapts to such a situation.

    With the support of buffer age, could we expect Kwin not to refresh the screen if nothing new has to be drawn (like windows Aero)? Or will it be possible with Wayland?

    I’ve begininng reading your blog for a few time, and you give me the will to contribute (unfortunately I don’t have the necessary skills yet. I’ve commanded the OpenGL red book to solve that)

    1. KWin does not refresh the screen when nothing has to be drawn. Don’t use the FPS effect for that – if it’s activated KWin has to draw. If there is nothing to draw, KWin is sleeping

      1. Cool, good to know!

        Could you explain what sort of improvement the support of buffer age will bring ?

        2. Support for Buffer Age allows Kwin to provide an entirely tear-free desktop while at the same time minimising the area of the screen that needs to be re-drawn: If only the blinking caret in Kate changed, then inly that rectangle will be re-drawn (and re-transmitted to the GPU). Without Buffer Age Support, you have to decice if you want your desktop to be tear-free (at the cost of huge repaints even for small updates) or minimise updates (at the cost of tearing for non full-screen updates).

          1. I thought KWin already does that… There was an effect to see where the screen is redrawn and if for example only the typing line was blinking on/off than it was showing that only that little line is redrawn.

            1. That’s only the area which goes through KWin for redrawing. As the OpenGL part is double buffered there’s also the need to keep the buffers in sync.

            2. Just read what I wrote:

              “Without Buffer Age Support, you have to decice if you want your desktop to be tear-free (at the cost of huge repaints even for small updates) or minimise updates (at the cost of tearing for non full-screen updates).”

              KWin decided to go with minimal redraws, which results in tearing.

  17. Good work, Martin. Waiting for stable release of 4.11.
    Thought you may be interested and happy to see the below link, I had tagged you in G+ on this but I think it got lost in other noise.
    Clem is planning to implement KWin like tiling in Cinnamon. Advantage of FOSS, other projects like Cinnamon can borrow ideas without any dread of patent infringements. 🙂
    http://segfault.linuxmint.com/2013/06/better-window-management/
    http://segfault.linuxmint.com/2013/06/window-snapping-in-action/
    Don’t get me wrong here. KWin is all powerful and have slowly started appreciating its feature but idiot users like me do not get to use some of the features either because it is hidden or settings bemuse us. (although such use cases could be common needs). For KDE5, more previews of effects and visual cues will be of great help to users.

    1. yes I had seen this comment and had read the blog post. It doesn’t suprise me, it’s a typical example for software evolution. Good ideas will be adopted by other projects and there is no point in denying that we came up with the quick tiling by ourself 😉

  19. Hi Martin,
    Just came by your blog, to say thanks to all kwin devs for your dedication to kwin and open-source, thank you!

  20. Pingback: Die wunderbare Welt von Isotopp

  21. Really great. Thank you and the other contributors for your hard work!

    I tried 4.11 last weekend, but kwin was showing a black screen. I switched between the differen opengl modes, but nothing helped. With disabled compositing, it was fine. I didn’t had further time to look on the bugtracker if there is already an bug report for this or if I have to report it, but I will do it next weekend.

    1. Sounds like the bug with color correction. It has already been fixed and beta2 will ship the fix.

  22. I cant wait for finall release. A specially screen corners effect. All that small thinks make kde the greatest desktop ever. Surelly I am waitting for human usable release of kwin with wayland support.
    All best.

  25. I would like to thank you for the work you have done for the free software community and I hope that you will keep doing great work. I read the blog post about fanboys and trolls. I am ashamed that a community with such great ideals can break a person so heard. Especially if it is a person like you, who shares the same ideals and is working so hard for them. I hope that one day, those people will be as ashamed as I am about their past actions.

    You do not deserve the stuff they throw at you. I hope you will stay strong and not let them get to you. I hope you will not get bitter or angry because of them.

    Know that I do not say this because I am a KDE fanboy. I do not like KDE for varying reasons and I support Canonicals move to Mir. But this is about respecting that people can have different opinions than you (I think Linus said something similar once). The world would be very bland if everybody did the exact same things.

    tl;dr: I feel ya, bro!

    1. Just for the record: the article was hardly about me. I just used me as an example. I have seen the same happen to many people and especially to Canonical.

  26. Good work on KWin, congratulation.

    I have just one question: Is it possible to turn off the new visual feedback on the screen edges? I much preferred the old behavior. If this is impossible at the time beeing, please consider adding such option.

  27. Is there a chance for better Effects JS API documentation?
    The one in Tutorial sections is an incomplete mess…

    Anyway — great release!

    cheers
    m

      1. I studied the linked article before, but…
        Well maybe my documentation reading and/or programming are not sufficient, but I couldn’t find out what exactly do parameters
        from: and to:
        in the Effect.Clip effect.
        In Effect.Opacity it is quite clear — to: and from: are single numbers (inside [0,1]?) regulating opacity at begin/end of animation.

        But for Clip these are pairs (x,y) (???, x,y\in [0,1]??)
        Cite (FPx2):
        This class contains two properties to describe two animation components individually (e.g. width and height).

        I tried to experiment with them for a while but I couldn’t see clear impact

        ps. This is the first time I try to code sth around kwin, so pardon my dumbness 😉

Comments are closed.