Tag Archives: KWin

KWin Effects written in JavaScript

Posted on by
9

Today I cannot make such a nice announcement as Aaron yesterday, but I can at least try announce something I personally consider as awesome.

This weekend I tried to make it possible to write KWin effects in JavaScript. After about two hours of work the effect loader was adjusted to load a Qt script instead of the library written in C++. This is a quite important step for the future of effects in KWin. It finally makes it possible to share effects via Get Hot New Stuff, so that our users can download new effects directly from the control module.

For packaging effects we use the well established Plasma Package structure, so that our script developers only need to know this one common way. The API itself will share as much as possible with the KWin scripting API – of course with adjustments for effects. For animating the API is based on the AnimationEffect introduced in 4.8.

From a performance point of view using JavaScript does not change anything. Our effect system has two phases: one to react on changes in the window manager (e.g. a window got activated) and one to perform the rendering. The scripting API only interacts with the window manager, so all the rendering is still good old C++ code – a similar approach to QML.

Now I guess you want to know what you can do with it. So here I present for example a Fade like effect written in JavaScript (for comparison: C++ version is > 200 SLOC):

var duration = 250;
effects.windowAdded.connect(function(w) {
    effect.animate(w, Effect.Opacity, duration, 1.0);
});
effects.windowClosed.connect(function(w) {
    effect.animate(w, Effect.Opacity, duration, 0.0, 1.0);
});

For us KWin core developers the scripted effects will be an important step as well. For quite some time we have been unhappy with the fact that there are too many effects which become difficult to maintain – especially if we have to adjust the API. With effects written in JavaScript this becomes much simpler. As we do not have to keep the ABI (API compatibility is enough) stable we can move effects written in JavaScript out of the source tree and make them available for download.

At the moment the JavaScript API is just at the beginning. But I expect it to evolve over the course of the current release cycle. For me the scripts are rather important as it also provides us an easy way to have device specific adjustments.

As I wrote currently the scripts do not operate during the rendering. Because of that we don’t have bindings for WebGL. This would at the moment not make any sense. Nevertheless it might be that we allow to upload custom shaders, but I won’t pursue such a task in the 4.9 cycle.

Create Temporary Desktops For Applications

Posted on by
18

There are applications which are more or less a mess for a window manager. For example The GIMP opens quite a lot of windows and you want to have all of those windows visible. In general you don’t want to have any other window on the same desktop

The solution to that is to move GIMP on it’s own desktop. But how? We can use static window rules to get this working, but what if there are already windows on that desktop? The perfect solution to that would be to have a desktop which gets created when you open GIMP and gets removed again when GIMP closes.

This was so far not yet possible without manual interaction. But with todays additions to KWin scripting this became possible. Here I present a KWin script which does exactly that:

workspace.clientAdded.connect(function(client) {
  if (client.resourceClass == "gimp-2.6" && client.windowRole == "gimp-image-window") {
    // create a new workspace for the Gimp image window (kind of the main window)
    // switch to the new desktop and send the gimp window to it
    workspace.desktops = workspace.desktops+1;
    workspace.currentDesktop = workspace.desktops;
    client.desktop = workspace.currentDesktop;
  } else if (client.resourceClass == "gimp-2.6") {
    // send all other gimp windows to the current desktop
    client.desktop = workspace.currentDesktop;
  }
});

workspace.clientRemoved.connect(function(client) {
  if (client.resourceClass == "gimp-2.6" && client.windowRole == "gimp-image-window") {
    // when closing the gimp window let's remove the last desktop
    workspace.desktops = workspace.desktops-1;
  }
});

I should really start to publish the quite useful example scripts I write to test the scripting functionality on places like kde-apps :-) The API for 4.9 is documented on Techbase

The Importance of Mentoring

Posted on by
6

Currently the KWin team is rewriting the work of two past Google Summer of Code projects. This is of course the worst thing which can happen about the projects. In retrospection we clearly have to say that the projects actually were failures – at least for the developer community. But both students succeeded their project, so we cannot say it’s the fault of the students. On the other hand the projects had different mentors, so blaming the mentors is too easy as well.

In this blog post I want to reflect why we consider the projects after more than one (respectively two) years as failures. What did go wrong and what can be improved in future projects? I hope this can be a help for more projects than just KWin.

I will base all examples on scripting – the project I am currently rewriting. Just to give an example of the scope: when scripting got imported into trunk it consisted of 3200 SLOC and now after the rewrite is almost finished it is down to about 500 SLOC which are mostly written by me. At the same time the provided functionality increased.

Don’t expect Students to Understand Complex Code

The scripting project should make it possible to have scripts run when “something happens”. E.g. if a window gets maximized the scripts should be notified. In the Qt way the best way to achieve that is by emitting a signal. Now this is what our student did. But in all cases I found so far the signals were emitted in the wrong place. So what is wrong?

KWin core works in a way that a user action triggers a method. E.g. entering the fullScreen mode will end up in Client::setFullScreen. But this method does not just perform setting the window to fullScreen, it also evaluates first whether it is feasible to set the window to fullscreen. For example the user might have established a window specific rule to disallow this window to go fullscreen. In that case the method will not change the state of the window.

The common pattern our student introduced was to emit the signal before the method had evaluated whether the window will change the state. So the scripts are notified with potentially wrong state change information.

Of course we cannot expect that the student for whom the code is completely new will understand these concepts. If you don’t know the internals of an application the behavior is in fact unexpected especially if it is only partially documented or commented.

Given this experience it is important to give a student enough time to get familiar with the rather complex code base. In this time it is important to provide the required help. In the example above it would have been a good advice to emit the signals whenever the effects are invoked – which happens at the same place (nowadays the notification of scripting and effects are merged) through direct method invocation.

Work in master

The Scripting GSoC got implemented in an SVN branch. For me as a team member and not being the mentor it was difficult to follow the development. In the end the branch got merged into SVN trunk without a review done by the team.

Some of the issues are resolved nowadays thanks to the git migration. So even if a student works in an own branch the team mates would get the commit mails and would be able to do a post-commit review on each commit. But still working in a branch for a long time brings disadvantages. Most likely the student is disconnected from the work. The team mates might work on the same code area, making merging more difficult – especially for a young developer who also has to learn to work with a complex VCS such as git.

So I think that it is most important to have the work been done in master (or any other development branch) directly. This might be tricky as KDE SC’s release schedule does not align well with GSoC, but as soon as the release branch is created there is no reason to not work on master.

Even while master is frozen the student should follow the common pattern and propose each change as a Review Request. This gives early feedback to the student and moves the burden of mentoring to the shoulders of the complete team. The team mates know what the student is working on and can provide early help and spot potential problems even if the mentor does not spot them. Remember: it’s not your student, it’s the team’s student.

Interfere before the student runs in the wrong direction

One of the tasks of a mentor should be to provide guidance to the student and ensure that the project goes in the right direction. I remember that my mentor did exactly that at one point were I started to do fancy stuff.

In case of the scripting project the student started to implement a kind of JavaScript extension for “Lazy Logic”. This was clearly not in the scope of the project, it might have been fun to implement for the student, but it’s nothing which is needed in a window manager. That’s just the wrong place to design new language features for JavaScript.

Given that the code was undocumented and I did not find any documentation explaining how this language feature works or why I would need it and last but not least I did not understand the code, it was one of the first code parts I dropped. This would not have been needed. The student should have concentrated on the task he is proposed to do.

Remember that the world is round

Yes, there are time zones. Yes most mentors have a day job and are restricted in the time they are available. It is no help to the project if the student works while the mentor sleeps and the student has to wait a day when he needs to ask questions to continue the project.

I remember that we had one project with the student living in Mexico and the mentor living in Australia. Of course this is a rather sub optimal combination. Don’t expect that the student will adjust his sleep rhythm. Even as a GSoC student he has the right for a normal social life.

Personally I decided not to mentor a student who doesn’t live in a European timezone. I just acknowledge with that, that I am constrained in time and that also all team members live in Europe, so we just cannot mentor students living on the other side of the world.

Communicate!

Communication is in my opinion one of the central aspects for a successful projects. During the project I mentored last year I tried to discuss the state of the project each day. And with communication I do not only mean e-mail or IRC, but also phone and personal meetings. If you live close to each other it might be a good idea to meet at least once, if the student lives in Europe Akademy is a must!

But communication is not only important with the mentor. Also with the complete team. The student should subscribe to the mailing list, read and answer review requests, be present in the IRC channel. His project benefits from it and the chances are better that the student stays after noticing how great the KDE community works.

Require Documentation

No code should be merged without documentation and without unit tests (if your project uses them). There is no excuse for a young developer to not write documentation. If the student works on a new area of code it is extremely important to have everything documented in a way that any of your team members can continue working with the code.

In case of scripting the code was lacking any documentation not even a high level description of the design was provided. This made it impossible to continue to work with the project. Trying to understand undocumented code can be more difficult than rewriting from scratch.

During a GSoC project you have the chance to enforce documentation. Make it clear that the student will not pass the final evaluation if the code is not documented. Documentation is not a nice candy, but at least as important as the code itself. Undocumented code is just unacceptable in the year 2012.

Be Prepared for the Worst

The worst for the developer team is that the student stops working with the last day of GSoC. This is bad but happens. The team has to be able to take over the project. A code dump is no solution and in doubt better not merge in the project than introduce bugs and instability. Yes that means that a GSoC project was wasted but it prevents a degeneration of the code base and does not bind your teammates to fix up the code.

In case of scripting we got a code dump which was completely undocumented and basically we have never seen anything of the student again. For me it would have been easier to just write the bindings from scratch than to fix up the project. Between the end of the project and my rewrite I had to fight several times with strange things done in scripting. So overall the project costs for the core team were higher than the benefits.

Adjust the proposed projects to the fact that the student will not be around after the project. $SUPERAWESOMEFEATURE is just bit crap if it cannot be maintained by your team. Use projects were you are sure that it will benefit the team even if the student will never touch the code again.

Adjust Your Own Expectations

Many mentors try to get just “cheap” work done and have the dream to get a new team member which might some day replace their position in the team. This might happen, but is rather unlikely. If that is your aim, you might head in the wrong direction. Now I can say lots about it, but there are people who can do that better, so I recommend to read the slides by Leslie Hawthorn from this years linux.conf.au.

The KWin team has learned from the experience with our failed projects. During last years project I was holding the hand of my student. For me it was important to get good code written and not much code or have him working on new areas. Also this year I will not mentor a project which would introduce a new area in KWin. E.g. Wayland support is out of bounds for a GSoC.

Aurorae 3: Window Decorations with QtQuick

Posted on by
29

Once upon a time there was a window decoration which was KDE’s default decoration. But years ago it fell into a deep sleep. The world changed while the decoration slept. Compositing was added, decorations received shadows, Qt introduced the graphics system raster and many many more changes.

Now after years the decoration temporarily woke up, but it is no longer a beauty, but ugly and old. The changing world made the decoration break. The decoration’s bits started to rot and this is visible. The truth is that the decoration will stay in the broken state as there is nobody who would want to fix it or anybody knowing the code.

What I just highlighted here is true for basically all old decorations. Of the decorations we ship only Oxygen and my theme engine Aurorae are maintained. This is a situation which can no longer continue. We have to face the truth and remove all old decorations.

But of course we don’t want to remove decorations without adequate replacement and this leads us to the story of Aurorae.

Aurorae was written to experiment with new features introduced in KWin 4.3. It was based on our common decoration API and by that is rather limited. So for 4.5 I decided to port it to the generic decoration API and reimplement with GraphicsScene instead of QWidgets. Aurorae allowed to download decorations through Get Hot New Stuff.

But given that it is a theme engine the possibilities are still very limited. Only what the theme engine supports can be rendered. Porting our old decorations to the theme engine might not be possible and not to be recommended.

But still we would like to have those decorations on a modern basis without the maintenance costs. So I started to port Aurorae to QML. This does not only give us a more powerful theme engine but also introduces QML bindings for window decorations, allowing everybody to write decorations with QtQuick.

So we can write themes without the limitations of a theme engine :-) This does not only remove 3000 lines of C++ code and replaces it by around 1000 lines of QML code, but also gives us an interactive decoration control module.

Interactive decoration control module

For Aurorae based themes all the buttons are interactive giving our users the possibility to really try the decoration before using it. But that’s not where it will end. I want to have new themes not based on Aurorae but using QML directly. For that I want to use the Plasma Package structure and would love to see integration in Plasmate. Another idea is to support deKorator themes inside QML.

But as always this does not come without disadvantages. Not all features which were possible with Aurorae will be available in Aurorae 3. Some features will also be dropped because hardly any theme makes use of the features, for example special backgrounds for non-composited setups. Aurorae 3 will hardly work without compositing, so it might be that we will make it a hard requirement somehow.

I hope to see many innovative QML based window decorations in 4.9.

What’s new in KWin Scripting?

Posted on by
12

First of all a happy and successful 2012 to everyone. Let’s work together to make this year a great success for KDE!

One of the big topics in 2012 for my development efforts in KWin will be JavaScript bindings and QML. This is a technology which will allow our users to build their own custom window manager giving even greater power to our static window rules as before. It will also reduce our maintenance need when major parts of our UI can be transitioned to either QML or JavaScript.

The work on this area has already started and the first code set has been merged into master (aka 4.9). The old scripting API had manually crafted bindings for around 30 properties for windows. Now the API is generated and everything that is available for effects is also exported to JavaScript, which means more than 60 properties, more properties than before are writable and many more signals are available. Interestingly I could drop several hundreds lines of code by exporting more properties and the code becomes cleaner and better documented. These are changes I really like :-)

The API documentation of KWin scripting is now auto-generated through Doxygen and already imported to techbase together with detailed Update Notes on what changed. If you run master and use KWin scripting be aware that you have to adjust the script. Exactly the same API will be available in QML and also the Effects API is very close – given that the property names are inspired by the Effects API.

One of my favorite changes is that our Plasma Desktop Console is now able to execute KWin Scripts:
Plasma Desktop Console executing a KWin script

To open just use KRunner and type the new keyword “wm console” or start the desktop console and switch using the toolbar button.

This is a very important change for me during development as I can easily test whether my scripts are correct and most important my implementation. But also for users it means that scripts can be tried at runtime and don’t require a KWin restart any more. So adjusting the runtime behavior becomes possible.

So what’s next? I am currently with the progress quite satisfied with the work done so far on scripting and will now concentrate on two other areas first: getting my unmerged kickoff-qml and screenlocker branch into master. Both require still a little bit of work. After that scripting and QML get my number one priority again.

KWin meets QML

Posted on by

Two years ago I started to re-implement the Window Switching capabilities of the KDE Plasma workspaces (also known as Alt+Tab or TabBox). The old implementation was based on a QWidget with custom painting which of course had some drawbacks. The new TabBox evolved into a framework around Qt’s Model-View concept to design your own window switcher.

Before I started to work on that area I did evaluate the existing Window Switching capabilities of the various desktop shells (both free software and proprietary solutions) and I noticed that all of them have drawbacks. None is the solution where I would say: that’s the perfect switcher.

The main issue is that depending on the user’s habits different work flows are required. A switcher optimized for users with few open windows fails for users with many open windows and vice versa. Especially thumbnails become useless for many open windows.

So I realized that we need something flexible enough to give users the possibility to use different layouts or to even define their own layout. This ended in a framework for window switching. The layout is described with an XML file and rendered through custom painting code in a Qt delegate.

When I implemented this framework I wanted to add a GUI to easily configure own layout. Unfortunately I never got around to implement this UI and I think there has never been any other layout except the default shipped once. It is a rather unknown feature and I’m quite unhappy that this great functionality never got implemented.

In the mean time the trolls did a great job to make UI development easier: QML. This makes it possible to do what I wanted to have for window switching: easy to design and exchangeable layouts. So this weekend I implemented the default (informative) layout in QML and plan to completely replace the existing View and Delegate code in 4.8. And this gives us the possibility to let users write their own layouts and to share and exchange them.

But this is only the beginning of usage of QML in KWin. I have many more ideas by making window thumbnails available to QML UIs in a limited way. This will allow us to even integrate the BoxSwitch effect into the normal window switching framework and replace the Window Strip in Plasma Active.

So great UI times ahead in KWin.

New Screen Locker

Posted on by

Some might have already read about it: we are currently working on a new screen locker. The old implementation is mostly a hack around X. There is the lock window which tries really hard to be the top most window. Obviously this does not often work, especially as the whole framework is way older than Compositing.

Too often I have come back to my system or resumed from suspend and seeing my windows shine through. Or seeing some notifications on top of the screen locker. We decided to change that and solve it once and for all in a proper way by putting security first and moving the screen locker into the Compositor.

The Compositor controls the rendering, so it can ensure that nothing gets above the screen locker. When we have the compositor being responsible for the screen locking we also get nice fading from and back to the desktop for free.

My initial idea was to just move the screen locker to KWin but not changing the unlock dialog. But now I started to play around with QML and need your help:

QML unlock dialog

You can see that I am really no expert in doing user interfaces. So if you have some QML experience or just want to help defining a very important area of Plasma, please get in contact with us. I will do all the JavaScript and coding, so that only the QML is needed.

The new way unfortunately conflicts with the existing screen savers. They are almost 20 years old and we have problems to keep support for them. At the moment we decided that if you have a screen saver configured the old implementation will be used with all the security issues. But we are not yet sure what to do in 4.9. As we use QML it would be possible to write new screensavers in QML. This would allow us to keep the improved security and to only need one code path. But we are unsure how our users will react on removing the X Screen Savers. To find that out we set up a poll on forum.kde.org and I would like to ask you to participate. This will help us to define our next steps.

The new screen locker will also be used by the first version of Plasma Active, which will be released in a few days. There we use the same architecture but ship a different QML file which does the unlocking without needing a password (we only want to protect for unwanted touch events). This shows that it is possible to exchange the QML files for custom screen savers.

Moving the screen locker into KWin has also more security advantages in addition to the protected screen content. Of course KWin is very crash resistant. So if the screen locker crashes KWin will just restart and lock the screen again. Even if KWin would completely fail it is more secure than before as without a window manager you can hardly do anything with the system. Also we have finally a real solution for the most often reported KWin crash of all time: the Intel driver crashes KWin when the screen saver is used due to unredirecting the fullscreen saver window. With the locker being a KWin effect it is impossible to trigger this driver crash.

Some users might wonder what that means if they don’t use KWin. Well as the screen locker has been moved to KWin you can no longer lock the screen if not using KWin (the same way you could not lock the screen if not using KRunner before). If you want to lock your screen in Plasma 4.8 but don’t want to use KWin you should get in contact with your Window Manager vendor. Sam from Compiz wanted to add support for it in Compiz. For anything else I don’t know. So why did we do it: we think that the security of most of our users is more important than the need of some users to use a different window manager. Also we had added many integration features to Plasma in the past and if you were not using KWin you lost these features. With the screen locker it is now exactly the same: you lose the integration feature when not using KWin. I also want to remember everybody who wants to complain in the comment section that the KDE Plasma Workspaces are an integrated product consisting of the Plasma Desktop Shell, KWin, KDM, Systemsettings and a few other applications. We develop this as one product, so if you want to remove a part, well that’s your decision, but we have to compromise and we clearly see that other vendors are integrating their window manager even further into the desktop shell than we do.

Power Saving and Desktop Effects

Posted on by

For a long time KDE Plasma offered to turn off Desktop Effects when battery runs low. In the past we changed the default to keep compositing on and now in 4.8 we remove the option completely.

We all care about power saving and so it is important to understand why keeping compositing on will most likely save more power than turning it off. (As with all hardware and driver dependent functionality we can only offer what is best for the majority of users, it is possible that with specific hardware turning compositing off would in fact save more power.)

So let’s have a look at what happens when you turn off compositing:

Turning Compositing Off

Window decorations

Our default window decorations uses a shadow build into the decoration itself. When you turn off compositing the shadow has to be removed. Given the way the shadow is implemented, this means that each window has to be resized and moved back to its position. Furthermore all window decorations have to be completely repainted.

Plasma

Everything that is painted in the desktop shell is a pixmap rendered from SVG. Plasma uses a cache for the recently generated pixmaps. The themes itself come in three forms: one for no-compositing, one for compositing and one for compositing with blur. When turning off compositing the theme has to switch from one of the two composited to the non composited. This means we need to access the hard disk to load the SVG. Then we have to render the SVG in the correct size to a pixmap and access the hard disk again to save the pixmap in the cache. This has to be done for each Plasma styled window: the panel, KRunner, the tooltips, Alt+Tab, Kickoff. Also in later states during using it is likely that the same cycle happens again: e.g. the size changes of KRunner. With compositing it’s most likely in the cache, with non-compositing it isn’t.

KWin itself

When turning off compositing KWin has to be quite busy. All the effects need to be turned down, lot’s of resources have to be released. The OpenGL context needs to be destroyed. The overlay window has to be removed, quite some properties need to be removed from the root window (support for blur, taskbar thumbnails, etc.), the manager selection has to be released. So overall quite some roundtrips to the X Server till everything is teared down correctly.

X Server

With compositing disabled the X Server becomes responsible for rendering the screen again. It no longer has to redirect the windows into offscreen pixmaps and notice KWin through the damage extension about changes. It has to update the screen and perform the clipping of the content. Pretty much the same what KWin did before.

How the Desktop Effects work

As we see overall turning compositing off is a rather heavy operation. It involves many applications, many context switches and lot’s of I/O. All the things you don’t want to do when running low on battery. But later on having compositing turned off must really bring power saving, right? To answer that we have to look on how KWin performs the rendering.

How KWin renders

KWin is notified by the X Server about an update in a window (damage) and triggers the next repaint. The repaint starts with asking all loaded effects whether they are active. In a normal situation only the blur effect will be active, all other effects won’t participate in the rendering. Each participating effect is asked to perform its transformations and additional rendering. In the normal case the blur effect notices that the window does not have to be blurred and does exactly nothing.

The windows are rendered from top to bottom. That is if we have an opaque window on top, the one below won’t be rendered. Only if it is translucent it will be rendered from bottom to top (that is all windows). So in the normal case (area of a window updated) only one window will be updated. The rendering itself is just a very simple 2D texture rendering. Yes it’s 2D, not 3D.

After the window is rendered KWin goes back to sleep to wait for the next damage event, it does not perform constant rendering.

But it’s using OpenGL, that’s expensive on the GPU!

Well think about it. Someone has to bring your updated windows on the screen. This someone is the graphics card. You need it anyway, no matter whether it is KWin or the X Server. KWin uses OpenGL to do the rendering, which means it’s hardware accelerated. I do hope that the X Server uses hardware acceleration to do it’s rendering ;-) In the most modern architectures (like Gallium3D) 2D is just a special case of 3D. I honestly don’t see how using X instead of KWin to perform the 2D rendering should save any power.

But can’t you at least deactivate the effects?

As explained above only active effects will participate in the rendering. So if you don’t use the cube effect, it won’t be used and cannot consume power. If on the other hand you use the effect than it is adding usability features. Imagine a user who switches windows using the Present Windows effect. Of course using this effect actively will affect the battery life. But what is worse? Using the effect once very shortly or searching a minute for the window in the taskbar? What will affect the battery life more? The minute searching (one minute less battery) or the animation?

But at least Blur should be disabled!

It is true that Blur is the most expensive effect we have depending on the hardware you have. That’s why we are optimizing the effect (thanks to Philipp for all the work on it). First of all: if the rendering of the window does not intercept any blurred area, the blur effect won’t do anything. If the rendering intercepts a blurred area the part has to be updated. Thanks to some optimization we only have to update this part and we cache the blurred background. So blurring is no longer that expensive as it was. Now we could nevertheless turn blur off, but that would require to generate new pixmaps (see above) and I doubt that this is better than doing some blur operations.

What about the animations?

Animations are probably the only thing where it might make sense to deactivate when running low on battery. Animations trigger repaints so they are not cheap. But to change that quite some work is required and I am not sure if it is worth it. So if you can do an evaluation on how expensive the fade effect is for the battery life we might consider to add a way to disable the animations.

Where Compositing helps to actively save power

There are operations where compositing is much better than good old X. For example when moving a window only some texture rendering need to be performed. With X the areas where the moved window used to be needs to be repainted. The same is of course true for resizing. Another advantage is that KWin renders with a well defined frame rate. No matter how often a window tries to render, KWin will throttle it. So a window generating damage events each millisecond will be rendered only each 17 msec. And yes there are applications out there trying to render as often as you can. Preferable some old icons in the systray or non-standard toolkits.

Where we enforce Compositing

KWin in 4.8 is the first version which will temporarily enforce compositing. This is currently related to the new screen locker. The new screen locker is implemented in the compositor to ensure that the screen is always blanked (something the old one could not guarantee). When we use the new locker KWin ensures that compositing cannot be turned off! So imagine we would allow turning compositing off when running low on battery.

First scenario: active usage. Compositing is turned off and later on the system goes to suspend and locks the screen with the old insecure implementation. I hope you all see that security is important.

Second scenario: screen locked when battery is running low. The power management functionality will try to turn off compositing, but it will fail and the power management will never notice about it. There is in fact no way how the power management could notice that and it would have to try again and again to turn off compositing. That sounds clearly wrong to me.

But 4.8 will hopefully have another situation where we need compositing: Wayland. When we run a Wayland server we will not allow to turn off compositing, because you would lose your Wayland windows. Currently the code is not yet merged and most likely the distros won’t have packages available anyway but it is something we have to plan for. With Wayland we need compositing, so turning it off doesn’t make sense.

Overall I hope you see that turning compositing off will be worse for the battery than keeping it on. We are concerned about helping the environment and giving our users the best of the limited resources. That’s why we removed the feature: to help you and not use wrong settings just because you assume that 3D is worse than 2D.

Second Strike for KWin Scripting

Posted on by

I already blogged about it: KWin Scripting needs help from the community if it should be available in 4.8. Unfortunately nothing changed about the state, except that I added a build flag to not compile Scripting.

I just wanted to apply a patch and got a compile error because of scripting and I remember that my GSoC student had also problems with scripting during his project.

So this is the second strike for scripting. And you know what will happen when I have to proceed to the third strike :-( Step up now, or scripting will have to go.

Rendering at 60 Frames

Posted on by

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