Blog: KDE KWin Miscellaneous Stuff

[menotu]

It's quite a large post listing bugs and code so I just pasted the first and last paragraphs
=====================================================

By Martin Gräßlin -  14. October 2012 (Martin’s Blog From the land of wobbly windows)

Maintaining history – done wrong

This week the Trinity Desktop Project released a bug fix release with very bold statements in their release announcement especially emphasizing on the 141 bug fixes and 1193 applied patches. Given that they include a fork of an application I know quite good I decided to try to validate their work on kwin. The release has been in work about a year and KWin has quite some bug fixes for reports dating back to the times of the forked application. I just used our bug database and searched for all KDE 2/3 bugs we fixed in the last year and I found the following 20 reports:

..........................

..........................

..........................

I think it summarizes nicely what one should expect from this project. I can only recommend everybody to keep away from the junk this project is producing. I’m quite glad they try to cut off all connections to KDE because this project is seriously harming the reputation of KDE.

http://blog.martin-graesslin.com/blog/2012/10/maintaining-history-done-wrong/

[Just17]

Whooooo!   Strong stuff!

[menotu]

By Martin Gräßlin -  14. October 2012 (Martin’s Blog From the land of wobbly windows)

A journey through virtualization (re OpenGL / VirtualBox / VMware)

This weekend I had a look on enabling the OpenGL compositor when running in a virtual machine. My assumption was that given that the next version of another distro is going to require OpenGL, there should be no problem with getting OpenGL running in a virtual machine.

I normally use KVM when I have need for a virtual machine running a Linux guest. As far as I know you cannot get OpenGL with this technology, so I hadn’t looked into it for quite some time.

My first attempt was to just use the project neon weekly build. Unfortunately I failed to convert it to a VirtualBox image, nevertheless I decided to run it and verify that KVM does not support OpenGL. Well I was rather surprised once the machine was up to see that OpenGL was functional, but well it was slow. Restarting KWin showed me that there is a missing slot (which I am aware of and is already fixed in one of the pending reviews) in master which makes the fallback to XRender not work, but KWin just uses llvmpipe. OK, result incorrect, but at least validated that KVM is not working.

I then decided to try VirtualBox with an install of Kubuntu Natty. Install went well but no OpenGL available. The Xorg log file told me that VirtualBox does not know the XServer version. Installed the latest version of VirtualBox, installed the latest version of guest additions in the Kubuntu guest, but no success: driver does not work.

So I decided to test with an outdated system, aka Debian Testing as I’m also running this on my workstation. Here I was more successful. After installing the system in the virtual machine OpenGL worked out-of-the-box. And what surprised me even more was that OpenGL in KWin worked when using KWIN_DIRECT_GL=1 and KWIN_COMPOSE=O. This means OpenGL works in general and it’s only blocked by KWin not knowing the driver.


The main reason is that KWin does not use direct rendering if it finds an unknown driver and VirtualBox only provides OpenGL in direct rendering mode. If LIBGL_ALWAYS_INDIRECT is set, it falls back to Mesa’s software rasterization and KWin sets this environment variable if it doesn’t know the driver.

With VirtualBox working I decided to also look into VMware.......................

Full Blog

[menotu]

By Martin Gräßlin -  9. November 2012 (Martin’s Blog From the land of wobbly windows)

Notice for users of KWin master

With KWin master as of today the configuration of the Translucency Effect changed. It used to have translucency values in the area [0.0, 1.0] which got changed to [0, 100]. If you rebuild and just restart KWin it might be that you do not see any windows at all, because the windows are completely translucent.

To circumvent this problem run the KConfig Update application in $KDEDIR/lib/kconf_update_bin/kwin_update_settings_410 or just log out and log in again.

Users not running master are of course not affected by the change, the KConfig Update handles it correctly on first login after update.

http://blog.martin-graesslin.com/blog/2012/11/notice-for-users-of-kwin-master/

[menotu]

By Martin Gräßlin -  5. March 2013 (Martin’s Blog From the land of wobbly windows)

War is Peace

Today I got many questions about KWin and Mir, how it affects us, what it means for our Wayland plans and so on. I did not want to write anything about it because I think there is nothing to write about, but before answering the same question again and again I think it’s better to put down a few lines here. Wiki will be updated once Wayland wiki is updated so that we have something to link to.

First question: Does Mir affect us? Yes, obviously. Because of Mir I have to write this blog post, Wayland developers have to get the FUD out of the Mir documentation, it’s creating tension and it harms the development. We will have to face again and again the question whether Wayland is better or not. So yes it affects us and I’m not happy about it.

Second question: Does it affect our plans for Wayland? I think it would be very unprofessional if we would change our plans just because Canonical did an announcement that they want to do an own display server for Unity (we didn’t throw away Plasma because of Unity either). Whether Mir provides technical advantages or not cannot be judged right now, we will have to wait and see, then we can make a decision whether it’s worth to change our plans. So far I have not seen anything in the documentation that would look like an advantage over Wayland. Given the incorrect statements about Wayland I’m very skeptical whether there can be any advantages. I don’t want to go into detail, just look on the Internet there’s already enough information about that. Also one should consider that Canonical changes plans for their distribution every other day. Just consider the number of toolkits which have been used for Unity – given that I would not bet on Mir will be used next year and that means of course that we should not consider it for our planning.

Third question: Will KWin support Mir? No! Mir is currently a one distribution only solution and any adjustments would be distro specific. We do not accept patches to support one downstream. If there are downstream specific patches they should be applied downstream. This means at the current time there is no way to add support and even if someone would implement support for KWin on Ubuntu I would veto the patches as we don’t accept distro-specific code. If Mir becomes available on more distributions one can consider the second question. Given the extreme success of Unity on non-Ubuntu distributions I’m positively optimistic that we will never have to do the evaluation of the second question.

http://blog.martin-graesslin.com/blog/2013/03/war-is-peace/

[menotu]

A few things that caught my attention
=========================

By Martin Gräßlin -  14 March 2013 (Martin’s Blog From the land of wobbly windows)

An update on KWin on 5

........................

 Over the last years some areas in KWin already made the transition from Plasma styled QGraphicsView to QtQuick, such as our Window Switcher or the Desktop Change OSD. But some areas remained: the close button in Present Windows and the add/remove desktop button in Desktop Grid. Here we have now a nice improvement ready for 4.11: these elements got rewritten in QML and they look way better now.



For comparison just do Ctrl+F8 or Click  here

The screenshot also shows another new improvement thanks to the transition to XCB. In the left upper corner a glow is shown when approaching the corner with the mouse cursor. If you use auto-hiding Plasma panels you already know this glow.

Also we plan to make KWin take care of the screen edges needed for the Plasma Panel. This removes quite some duplicated functionality from Plasma and solves the general “problem” that Plasma cannot listen to just all mouse events in a Wayland world.

One of the areas which has seen most adjustment so far is our XRender based compositor. It was a heavy user of the QPixmap/X pixmap relationship and needed to change. I still consider XRender as an important part of our compositing offering and therefore decided to do the porting.

Interestingly the porting did also bring improvements to our OpenGL compositors. Again the reason is that we had to rethink. Our decoration rendering code used the QPixmap/X Pixmap relationship from the time when KWin only supported the native Qt graphicssystem. When we did the transition to raster the code did not get adjusted to the new world and that’s why we for example recommended the native graphicssystem for XRender.

With the native system going away we just had to make it better and the improvements made for XRender benefit the OpenGL compositor in the same way. With Qt 5 I hope that we can get some further improvements for the QtQuick based window decorations. I was running KWin on XRender with raster and Plastik-QML as window decoration and was positively surprised: I couldn’t notice a difference in the speed compared to the OpenGL backend.

Full blog

[menotu]

By Martin Gräßlin -  25 March 2013 (Martin’s Blog From the land of wobbly windows)

Setting up a Pandaboard for KWin development

The Pandaboard is a nice little ARM powered device which is meant for development and suited for example to test KWin on real OpenGL ES hardware. This weekend I decided to set it up again, I had done it before, I had installed KWin on the PI, so I’m not a complete NOOB for ARM hardware. I wanted to test a few things and see how the latest changes to master do on a non x86 architecture.

I got the memo about Linux is for normal users and not for LEET, but I do not understand why it has to be so difficult to setup a device which is meant for development. In the past it was as simple as dd an image to an SD-card, plug it in and done. Well those times are over.

Full blog

Earlier post

[menotu]

Posted by Michael Larabel on April 01, 2013

Intel Mesa Driver Gets KDE KWin Optimizations

A number of commits to the i965 driver in Mesa today benefit the performance of KDE's KWin window manager for those using Intel Ivy Bridge graphics hardware.

There were a number of commits pertaining to the i965 driver's fragment shared pushed this afternoon (i965/fs). Most notably, this should help Ivy Bridge with KWin when using the scaling-related effects using the OpenGL 2.x renderer.

The bug report relevant to this Intel IVB OpenGL performance regression is covered at FreeDesktop.org. There's several commits relevant to this optimization work. One of the commits by Eric Anholt also mentions a significant performance improvement with one of his GL Shading Language demos.

    Like we have done for the VS and for constant-index uniform loads, we use the sampler engine to get caching in front of the L3 to avoid tickling the IVB L3 bug. This is also a bit of a functional change, as we're now loading a vec4 instead of a single dword, though we're not taking advantage of the other 3 components of the vec4 (yet).

    With the driver hacked to always take the varying-index path for all uniforms, improves performance of my old GLSL demo by 315% +/- 2% (n=4). This a major fix for some blur shaders in compositors from the varying-index uniforms support I introduced in 9.1.

It also looks like the newly-merged patch series takes care of some Sandy Bridge performance issues too.

http://www.phoronix.com/scan.php?page=news_item&px=MTM0MDU

[menotu]

Another item I'm sure some have wondered about is the.settings in

systemsettings > Common Appearance and Behavior >  Application & Appearance > Styles > Fine Tuning

Low display resolution and high CPU - Does that meant it uses more CPU power for low resolution?
High display resolution and low CPU - Does that mean to reduce CPU power for high resolution?

The following link is a few years old but does question what the high res/low cpu etc actually mean

one reply by boooksley says

Unfortunately, the Oxygen developers don't know what it means, or does or if anything actually uses it. It is likely a legacy element, and can be ignored.

From http://forum.kde.org/viewtopic.php?f=17&t=90862

What is the Graphic Effects setting supposed to do?

In KDE 4.4.4 and 4.5 System Settings under Appearance>Style>Fine Tuning tab there is the following setting for graphic effects. Can someone please explain what it does and how it works because I don't seem to see any difference in the effect the settings have. By default it seems set to low display resolution and high CPU. This seems opposite to what one would expect it to be.



How are the different options meant to be interpreted? For example the two options below seem counter intuitive. Do you take the interpretation literally as in

Low display resolution and high CPU - Does that meant it uses more CPU power for low resolution?
High display resolution and low CPU - Does that mean to reduce CPU power for high resolution?

Or is it meant to be interpreted as priorities?

Low display resolution and high CPU - Keep the priority of low resolution and high cpu i.e. it will reduce the display resolution / effects to free CPU power.

High display resolution and low CPU - Here the display resolution has a high priority over the CPU, i.e. it will force all the resolution / effects to look correct at the expense of using up a lot of CPU power.

It still doesn't make much sense to me which ever way you read it. If it's referring to actual display resolutions / effects, most graphic adapters have their own GPU's so don't really impact the main CPU. Completely confused.

[menotu]

By Martin Gräßlin -  12 April 2013 (Martin’s Blog From the land of wobbly windows)

Hitting walls – a story of Present Windows 2

One of my favorite User Experience elements in KWin is the Present Windows/Desktop Grid combination. For me those are the most important elements to switch between windows and virtual desktops. Although Present Windows and Desktop Grid are two different “effects”, I consider them us one because of their very similar functionality. The primary use case for both is to change the active window, the main difference is that Desktop Grid sorts the windows by virtual desktops.

The effects are so similar that they even share the code to lay out the windows. Nevertheless there are quite some differences in the functionality. The following features are only available in Present Windows:

    Filtering of windows
    Icon and caption on each window
    Closing windows through a button shown on hover
    Enlarging windows on hover
    Mouse Actions
    External activation (used by Netbook Shell)

On the other hand there are features in Desktop Grid not available in Present Windows:

    Drag windows from one screen to another
    Add/remove virtual desktops

The difference in functionality cannot be explained – there is just no reason for it. This is clearly a problem for our users – the effects look identical, but they behave differently. From all I learned about usability this is pretty bad because it teaches users to not trust systems.

The obvious answer would be to merge those two effects. But here we have a problem. Present Windows has been implemented to be Present Windows – no matter how we tweak it, it will be Present Windows. And Desktop Grid has been implemented as a Desktop Grid – no matter how we tweak it, it will be Desktop Grid.

Full blog

[menotu]

By Martin Gräßlin -  24 April 2013 (Martin’s Blog From the land of wobbly windows)

Good bye Notifications

When I arrived at Tokamak 6 last week Alex was studying D-Bus communication between various applications. Before I had a chance to really sit down he complained about KWin talking to kded whenever for example a window got moved. This didn’t make much sense, so we had a look at it.

As it turned out that was KWin sending out notifications. Which immediately raised the question of why? Why would a user want a notification that he started/finished moving a window? After all it’s an action the user triggered. What should be done with the notification? Show a message? “You successfully moved a window!”, yes thank you I can see that on the screen. Play an annoying sound? Pling! Hopefully not.

Looking at what KNotify supports only logging to file or running a script make sense in response to the notifications emitted by KWin. But for logging to file it’s rather questionable why one would want that and why one would do that from inside a window manager. So what remains is running a script – fair enough that can be useful.

A closer look to the notifications emitted by KWin showed a few more things. None of them is configured to do something with the notification. By default KNotify just discards the notifications. This means we do a communication with kded via D-Bus for nothing. Two applications are getting woken up, context switches and so on for exactly nothing. Some notifications have a sound file connected to them, but are not configured to play that sound by default. We made a small quiz by me playing the sound file and letting the rest of the group guess what it’s for – I think nobody got one right. Nobody of the core workspace developers knew these sounds.

Looking at the code where the notifications are emitted highlighted another interesting fact. At all places we also emit a Qt signal which is mapped into the KWin scripting environment. And that’s actually quite awesome. Because unlike the notifications it has context. A KWin script does not only get informed about a window that gets moved, but about which window gets moved. Let’s say you are only interested in movements of Firefox windows – with KWin scripting that’s possible, with the notifications it isn’t. Given that we already identified that scripting (and maybe sound) is the only use case for the notifications emitted by KWin it’s getting more questionable why they are still around. Obviously they had been added long before we had KWin scripts. I was unable to really figure out when it got added, as git blame ends in one of the moving around code commits years ago (with more patience one can figure it out, but knowing that it’s old, was enough).

Of course we do not want to break our users’ workflow, so removing the feature is not easy. We have to properly judge whether the users’ workflow is valid enough to penalize all users by the additional overhead in code and in communication especially the context switches. Given that KWin scripting also allows to perform D-Bus calls, it should be possible to rework each of the previously existing notifications in KWin scripts.

That said: in case you were a user of one of those notifications and the removal breaks your workflow: please let me know. Please tell me how you used it and best provide your script. I will have a look at it and try to ensure that it’s still possible with KWin scripting (if it’s simple enough I will just port it).

http://blog.martin-graesslin.com/blog/2013/04/good-bye-notifications/