Posted on

Rendering at 60 Frames

Full credits go to Alex Fiestas for complaining about the performance in a way that I wanted to do something about it, instead of being just annoyed and ignoring the comment!

Alex’s complaints got me wondering why we are not able to render 60 frames/second. Each frame should only take 16.67 msec and knowing that our repaint loop is fine, I could not imagine how a frame could take longer to render than the 16.67 msec. Knowing the KWin’s source code pretty well I suspected two parts of the repaint loop to be slow: the method which actually renders each window and our effect chain. The effect chain calls each effect in turn to transform windows. I had an idea to improve the effect chain for quite some time by calling only the currently active effects. That is currently each effect checks first whether it is active and just does nothing. So you basically call all effects again and again and nothing is actually performed except waisting cycles on checking whether it should do nothing (some effects are heavy there).
Of course I do not just optimize without checking if the code needs to be optimized, so I did an analysis of callgrind output and I was surprised. The effect chain was way more heavy than expected. In fact it’s so heavy that the paint method doesn’t matter in comparison. A deeper analysis of the code showed that there is a small bug, which we will fix in 4.7.2 (too late for 4.7.1), so that we can give the benefits as fast as possible to our users. But the real optimization by only calling the active effects will hit only 4.8. After that change the effect chain is no longer visible in the hot pathes of KWin. Also the change immediatelly helped to identify some expensive checks in some effects which are now ensured that they are not called in each frame (unless the effect is active).
After the optimization of the effect chain we are still not yet there and do not reach 60 frames during the animation, but you can really feel the improvements 🙂 Now the paint method shows up as one of the most expensive in callgrind (as expected previously) and I will now spend some time and thinking in how to optimize this one further by moving heavy operations out of the repaint loop.
In the long term I hope to be able to move the compositor into an own thread (also something I have in my mind for quite some time), so that heavy operations in window management and the decoration plugin do not slow down the repainting of the compositing. This might be tricky as we can run into dangerous deadlocks (imagine compositor and window manager both blocking the X Server), so we will probably first concentrate on moving e.g. texture loading into threads – something one of our new deelopers in KWin experimented with.
Overall very nice improvements, I’m happy with, but not yet satisfied as we do not yet reach the constant 60 frames/second.

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

Posted on

Thoughts about KDE Plasma on non-Linux Systems

This post represents my personal opinion. It does not need to represent any official opinion from any association I am involved with.

The Readme of the KDE Plasma Workspaces states clearly that our desktop is an X11 desktop environment:

KDE Workspace consisting of what is the desktop. The applications and libraries included aren’t required to b e portable and probably will only work with X11. On other desktops such as OS X and Windows, users wouldn’t r un these applications, but use the native ones instead. The typical application shouldn’t have dependencies i n workspace unless they are a component such as a screen-saver or panel applet.

So what does that mean? Our base system should work on every operating system supporting X11. Be at Linux, FreeBSD or Solaris. But how does the world look like, is this still the truth?

The world around us is changing and I would say that the statement is no longer true and soon needs to be adjusted to also include Wayland. This shows that we are at the point thinking beyond the X Windowing System. So what does that mean for the operating systems we support? At the moment Wayland is a Linux only system and given the current requirements it looks unlikely to be supported by non-Linux systems any time soon.

Wayland is of course only one example. There are more. Think about the deprecation of HAL or introduction of systemd. HAL we are still able to support in KDE thanks to our good hardware abstraction through solid. Systemd is not yet used, but I hope that this will change soon. Given these changes we must face the from a technology point of view all non-Linux are far behind Linux which means that on the long supporting the legacy technologies only for non-Linux becomes more and more a hurdle.

Personally I do not know any core developer of the KDE Plasma Workspaces using a non-Linux operating system. So you would expect that we have lots of bug reports for the non-Linux OS. Given that we already have hundreds of bug reports in KWin just about the stack on Linux which we use, there have to be even more for the non-Linux systems. No dev uses it, it gets not as tested as our Linux system, so there have to be bugs! So here the stats for KWin over the last 12 month:

  • Linux: 1054 opened bugs
  • FreeBSD: 4 opened bugs
  • Solaris: 3 open bugs

All three Solaris bugs are actually build errors on Solaris containing patches – they should have been opened on reviewboard. Due to miss of quality non of the patches was included in the software. From the four FreeBSD bugs, two are crashes lacking debug symbols – something that does not happen on Linux any more. One bug was actually also present on Linux, but seemed to only apply for legacy technology. So we have something like 250 bug reports for Linux for each non-Linux bug report.

For Plasma it’s 3529 bug reports for Linux compared to 30 non-Linux (only X11). From the seven Solaris bugs, six are again build failures. FreeBSD are mostly crashes again with missing backtraces and so on.

So this tells us that basically Solaris does not have any users and that it only creates work for us, because they use different compilers. Nevertheless we do not seem to accept the patches. So it’s great that Solaris wants to provide packages for our workspaces, but it should not create work. And yes reporting a bug and discussing it and even rejecting a patch is creating work.

And there is more we have to consider: KDE Plasma Workspaces are nowadays more than a set of applications for X11. It’s an integrated system providing a consistent user experience. Important parts of this experience is also our Oxygen design which does not only require compositing but also advanced OpenGL effects such as the Blur filter. Unfortunately free drivers are not able to provide these requirements on non-Linux systems due to lack of KMS and Mesa frozen at the last version before KMS. What we provide for non-Linux does not match what we want to provide.

The free desktops still have a considerably small market share, but as also the bug reports show the non-Linux users make less than one percent of our user base. If we now think about the global market share for non-Linux KDE Plasma systems we come to a number very close to 0. Our resources are spare and we should make the best out of it. Spending time on hardly used systems which are lacking behind in the technology we want to use and cannot provide the minimum requirements for our workspaces, does not sound like a sane idea to me.

To me it is clear for quite some time already that I won’t accept patches any more for non-Linux. Including another code path or even a build flag for non-Linux systems is not worth the increasing maintaining costs. If non-Linux systems want to include patches they should do it downstream.

Also for the inclusion of new technologies we should not wait for the non-Linux to catch up or do sacrifices in order to still support non-Linux. If a new technology brings us great advantages on Linux but means we have to stop supporting non-Linux because they do not provide the technology, I think it’s better to be really good on the one system.

Please remember: this is my personal opinion.

Posted on

Smooth Window Resizing

As Thomas does not blog and this is quite impressive, I had just to do a video and provide it here. Without further ado I present smooth window resizing with KDE Plasma 4.8:

(Direct Link)

Much Kudos to Thomas for fixing the XSync implementation inside KWin!

Posted on

Guest Post: Crash – Exam – Relaunch

This is a guest post from my Google Summer of Code Student Arthur Arlt.

Isn’t it a funny title for a blog post? But there is a reason for that because it happend a lot in the last weeks…

Crash

Having done my first review requests for my GSoC project, my new (six week old!!!) solid state drive stopped working from one moment to the other. I tried to get it running in other systems, but it was no longer detected by any BIOS. Taking a look at the homepage of Kingston I had to discover, that they found a technical issue of exactly that brand of SSD I had installed to my system. They are strongly recommending to do a firmware upgrade because this failure could lead to a total crash of the drive…
Thanks for the information 🙁 Luckily I made my review requests before, so at least the work done for GSoC so far was saved. But everything I did in these six weeks on my laptop is gone…
I got the SSD replaced, but this took almost two month, since the producer had to check by itself that the SSD is broken… So I bought a new one, because it was no fun working with my slow, old HDD.

Exam

I did not have too much time to be angry about the loss of data. I had to study for an exam in “Principles of Dependable Distributed Systems” which took place at Friday before Whitsun. After that, I have spent a lot of time to (re-)set up the build environment during the holidays.

Relaunch

I am now working into Martins hands supporting him to port KWin to Wayland. Especially the class Scene and its subclasses were provided with some signal and slot functionality.
A very important step to Wayland is to remove all X11 specific stuff from class Toplevel and to insert it into a new class XWindow which will then provide the functionality for X11 based windows. This refactoring emerged to be too difficult at that moment and Martin and me decided to do some other refactoring first. The parts I am currently working on is on the one hand to move all Workspace functions implemented in the file composite.cpp to an own class Compositor. On the other hand I am introducing a new class
DecorationPaintRedirector, which handles the composited decorations.

Work done so far

Some functionality of KWin was moved to own classes or even deleted. For example the broken functionality of TopMenu was removed. The functionalities of screen edge handling and Tabbox were moved to its own classes. The same happend to the tiling functionality. I also added some build option to chose whether KWin should be build with or without supporting a specific functionality. These build options are provided for Tabbox, Tiling, DesktopChangeOSD and ScreenEdges. They are automatically deactivated if building KWin for mobile devices is enabled.

Benefits

Thanks to the refactoring work done so far some parts of KWin are better structured and readable as before. One thing which confused me when I was starting coding for KWin was that in one file there could be several classed implemented. That issue was changed for some classes like Tabbox and Tiling by introducing new files or classes and by moving the related functions to the appropriate classes. These changes do not only make the code better readable but also better maintainable.

Desktop Summit

Two weeks ago I attended the Desktop Summit 2011 in Berlin. I was helping as a volunteer for video operation. Since I did not know anyone there, doing the volunteer work was a great decision. I never expected that I will get to know so many nice people. I was talking to other GSoC students and we were telling each other about our projects and the current state. Meeting some developers of KWin and Plasma was a great occasion. It’s kind of funny meeting them in real life if you had only virtual contact before 🙂 Last but not least the daily social events were the best opportunity to meet new friends. And one can say: Partying with open source people kicks ass!
The days in Berlin were very exhausting, but I had a wonderful time and I don’t want to have missed it.

Outlook

The GSoC project “Modularization of KWin” did not have a specific goal to reach, since we did not know how much work it will be to refactor all this stuff. One can say that there are still lots of things to do, but I am satisfied with my work done so far. The main point for me was to get into the community and I can say that doing a Google Summer of Code is a great opportunity to achieve this. I am really looking forward to go on with my contribution on KWin because it is really fun working with such a great team.

Cheers,
Arthur

Posted on

KWin turns 12

Today twelve years ago at 23:26 Matthias Ettrich did the first ever commit to KWin:

Say hello to kwin. WARNING: NOT USABLE YET. See README.

Given this nice warning we also have to show the content of the README:

This is the beginning of kwin, kwm next generation.
WARNING: this thing is hardly usable now, neither ICCCM nor KDE
compliant yet!
All it has is a context menu that allows you to switch between two
decoration styles, KDE classic and an experimental style.
Please don’t work on the code, I’ll finish it during my summer
vacations (four weeks from now on).
kwin was only commited to allow people like Mosfet to have a look at
the Client API (and StdClient) to write nifty new themable decorations.
Have fun,

   Matthias

As we can see KWin has its root in KWM from KDE 1 (there are still one or two comments in KWin source tree saying KWM) and it seems like the capitalizations was added in later times 🙂 
Matthias seems to have been a little bit too enthusiastic about how much time it needs to write a window manager. It took 8251 commits (1195 translation commits) by 284 contributors (including scripty and cvs/svn migration tools) to get to where we are today. And still we are not finished with KWin. After adding Compositing Support to the Window Manager we are now adressing the second big transition to support more than just X11. So exciting times are ahead of us.
Let’s work together to make KWin rock the next 12 years even more than the last 12. Billions of devices are out there which want to be using KWin as their Wayland Compositor. Let’s work on the future for the free software eco system!

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

Posted on

Thoughts about Network Trancparency

Every time there is an article about Wayland you can see that there a lots of uneducated comments about the “fact” that Wayland does not support network trancparency and because of that it is completely wrong to go for network trancparency. These discussions contain a lot of myths and even FUD and I consider it important to share my thoughts about these concerns as I am belonging to those who actively work to bring the benefits of Wayland to the KDE Plasma Workspaces.

Wayland Could Use Network Transparency

Nothing in the Wayland protocol forbidds network transparency. It is not yet implemented, but it is possible to implement it. Wayland uses a Unix Socket for communication but I think it would be rather trivial to either add network transport to the Wayland protocol or to just forward the buffer in the compositor. Stating that Wayland does not support Network Transparency in general is just wrong. It’s not yet implemented but many things are not yet implemented. Obviously it’s true that the Wayland protocol does not support the X11 Network Transparency as it’s not X11 (and that is a good thing). Obviously even a direct X11 successor (let’s name it X12) would also not support the X11 Network Transparency.

X11 Network Transparency is not Suited for Modern Applications

The idea behind the network transparency is to send drawing commands over the wire (useful idee for the requirements of 30 years ago). Nowadays modern applications do not use X11 any more for rendering. They use technologies like Cairo, Clutter, QPainter (Raster) or OpenGL directly. Without using X11 for rendering you end in streaming pixels over the wire. And there are clearly better technologies to do that than X11. Face it: network transparency is going to break very soon even without Wayland. I want to see the Qt 5 used over the wire.

Modern Applications require DBus

Yes DBus is not network transparent and yes most modern application use it, for things like StatusNotifier (this one has fallback to Xembed) or moving the menus somewhere else. Now without network transparency these things are just shown on the wrong system or not at all. Damn stupid devs not thinking about network transparency… So face it: no modern app can be used without DBus which breaks implicitly also the X11 Network Transparency.

Wayland targets Mobile Devices

Those who attended my presentation at Desktop Summit or who have seen my slides might have already got the message: we don’t want to break the desktop and will therefore only target mobile devices in the beginning. The same is true for MeeGo (they don’t have a desktop) and hopefully also GNOME Shell and Unity. So do you really want to forward your X11 application from your (mouse+keyboard) desktop to your touch tablet/smartphone? Probably not. So why do you care about network transparency not available on mobile? For mobile the target groups are the billions of users out there who do not even know that network transparency existed and not the five geeks who cannot live without it. Face it: you are not in the target group of Wayland on mobile devices if you need network transparency. (You probably wouldn’t use an iPad either).

Desktop will continue to Support X11

We will only switch to Wayland as our primary windowing system if we can continue to support legacy X11 applications, because we don’t want to break the desktop. This means you can still run your legacy X11 windows over network even under Wayland and also X11 applications on the Wayland system can still be forwarded to a remote system. So I hear you already complaining about the Wayland windows not being able to be forwarded. Well if the toolkit (like Qt) supports multiple backends there is no reason why you should not use the X11 backend to forward the window. Apart from that: remember, it would not be working at the time when we switch to Wayland even under X11 (see above).

Network Transparency Does Not Belong Into The Windowing System

Adding Network Transparency in the Windowing System is the wrong layer. The windowing system only receives the pixels and that can never be performant. Network Transparency needs to be added to the layer which does the rendering. That used to work with X11 as X11 also did the rendering, but this is not true any more. We need support for Network Transparency in the toolkit. Just imagine the possibilites: remote applications picking up your local font settings, color themes, icon themes… That’s what needs to be done!

But Distros will remove X11 support in $X Years

As long as there is a demand for legacy support distros will still support it. Especially I don’t think that enterprise distributions will dare to remove it in the next 10 to 20 years. Remember that also Mac OS X still supports legacy X11. And even if the distro removes the support: who stopps you to package X11 yourself and provide it to everyone who needs X11? Btw we are talking here about at least three to five years – others have predicted the death of desktop till then.
I hope this post can help to bring future discussions about Wayland to not keep repeating what has already said and is just wrong.

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

Posted on

KWin at Desktop Summit

Wow, what a week! It’s just great to be at Desktop Summit again and meeting all those KDE people again and also the GNOME people which gives the event a different and pleasant touch.

The big topic for me at this Desktop Summit is to lay out the foundations for bringing the KDE Plasma Workspaces from the X11 Windowing System to the upcoming Wayland windowing system. This is an effort which will most likely take years, nevertheless I am hoping that we find enough interested developers to have something ready as a developer preview in our next release. The complete plan has been outlined in my presentation here at Desktop Summit. It seems like my slides and video recordings are not yet uploaded, but I put my slides in our wiki. If you can read German you can also have a look at my article in the current issue of freiesMagazin, where I wrote down what I talked about.
As there was some media coverage about my talk and also about other changes in KDE which are completely unrelated I just want to point out that the work going on for KDE Frameworks 5 does not influence our development of the desktop at all. This means we will continue to release further 4.x releases of the KDE Plasma Workspaces. Also given the changes which are going to happen in KDE Frameworks it will not be disruptive to the desktop. This means that there is no reason to use a “5.0” release to switch the windowing system from X11 to Wayland. We will switch when we are confident that we do not break the users’ desktops.
I also read some concerns about that we would remove the X11 Network Transparency. Relax: we don’t want to break our users’ desktops. Just have a look at this architecture:
As you can see even with Wayland as the windowing system we will continue to support remote X Clients.
Yesterday we had a BoF about the changes needed for Plasma. We did unfortunately not agree on that much, but I will put up a wiki page with small TODOs, so that others can work on it. The BoF turned out into a discussion about Client Side Windowdecorations, which I did not want to spend time on. But in the end I think it was useful as now developers from other projects understand our position better and can understand why we will stick to server side decorations even with Wayland. I will soon write down a policy to exactly specify when windows will be decorated and when not and implement it for 4.8 (should only require minor changes).
On a completely unrelated note: thanks to the decision of three persons, I will be going to Akademy 2012. Thanks very much for the award.

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

Posted on

Continuous Integration for KWin

I decided that the life for my server is too boring as its only used to host this blog and functions as my mail gateway. As the system is rather powerful I decided to setup a Jenkins installation in order to continuously build KWin.

The first step is finished: the kde-workspace repository gets polled regularly and whenever there was a commit to master the sources are rebuild and in case it breaks I will be notified by mail. As KWin is not a standalone project, the complete kde-workspace repository is rebuilt. I want to further improve this process by doing several builds with varying configuration (e.g. the build for Plasma Active) and also for the kwin-wayland branch. But for those I first need to build a recent version of Mesa (no OpenGL ES on Debian Squeeze).
The really useful part of a CI system is that you can also perform some checks on the code. Unfortunately KWin does not yet have any unit tests (it is rather difficult to unit test an X11 Window Manager and OpenGL Compositor), but thanks to our modularisation effort I’m confident that we will soon be able to integrate the first unit tests.
But there are of course other possibilities except running unit tests. So I integrated a cppcheck execution on KWin’s repository as well as setting up Krazy tests, which are unfortunately broken for kde-workspace on quality.kde.org. Due to the lack of automated Krazy runs I have not managed to keep track of the issues lately.
I hope that these efforts help in the long to improve the quality of our software and to ensure that the code doesn’t break with unusual build options especially now when we transit to a major new windowing system.

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

Posted on

Shadow and no Oxygen

All users who do not use our default Oxygen widget style and window decoration might have had an unpleasant surprise after upgrading to 4.7. Our old shadow effect provided generic shadows for all windows no matter which widget style or decoration is used. In case the decoration provided its own shadow that one was preferred.

The new shadow system does not provide any generic shadow. The compositor is just providing a service to the widget style for rendering the shadow. This means that the widget style has to implement support for the new shadows. This has been done at least for Oxygen and Bespin, but it might also be added for other styles – so if you miss your shadows, check whether there is a new version of your preferred style, get in contact with  the author of the style or best of all: provide a patch.
Of course there is also the option to add a generic implementation again to KWin (which seems to be a need), though I must say that I will not spend any time on that myself. Given the experience from our old shadow effect, it is my belief that you cannot have a generic shadow which looks good with all widget styles, windows and color schemes. Nevertheless I am open to patches which add a generic shadow which can be used if decoration and widget style do not provide a shadow. The basic ideas of the new Shadow system are documented in our wiki. If you want to work on it and have questions just get in touch with us through either #kwin or #plasma on freenode or kwin at kde dot org.

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