Author Topic: Blog: KDE KWin Miscellaneous Stuff  (Read 2684 times)

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: KDE KWin Stuff
« Reply #15 on: October 14, 2012, 05:33:09 AM »
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/
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline Just17

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 11071
  • MLUs Forever!
Re: KDE KWin Stuff
« Reply #16 on: October 14, 2012, 09:07:41 AM »
Whooooo!   Strong stuff!

MLUs rule the roost!

Linux XPS 3.4.48-pclos1.bfs  64 bit
Intel Core2 Quad CPU Q9450 @ 2.66GHz
4 GB RAM
MCP51 High Def Audio
GeForce GTX 550 Ti
PHILIPS  ‎DVD+-RW DVD8701
‎Logitech ‎BT Mini-Receiver
Afatech DTT

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: KDE KWin Stuff
« Reply #17 on: October 14, 2012, 12:20:29 PM »
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
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: KDE KWin Stuff
« Reply #18 on: November 09, 2012, 05:46:16 AM »
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/
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: KDE KWin Stuff
« Reply #19 on: March 06, 2013, 04:18:04 AM »
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/
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: KDE KWin Stuff
« Reply #20 on: March 15, 2013, 06:13:22 AM »
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
« Last Edit: March 15, 2013, 06:15:38 AM by menotu »
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: KDE KWin Stuff
« Reply #21 on: March 26, 2013, 07:28:00 AM »
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
« Last Edit: March 26, 2013, 07:31:21 AM by menotu »
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: KDE KWin Stuff
« Reply #22 on: April 02, 2013, 04:44:37 AM »
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
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: KDE KWin Stuff
« Reply #23 on: April 03, 2013, 08:46:33 AM »
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.

PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re:Blog: KDE KWin Miscellaneous Stuff
« Reply #24 on: April 13, 2013, 06:07:52 AM »
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
« Last Edit: April 24, 2013, 10:20:32 AM by menotu »
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: KDE KWin Miscellaneous Stuff
« Reply #25 on: April 24, 2013, 10:11:25 AM »
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/
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: Blog: KDE KWin Miscellaneous Stuff
« Reply #26 on: June 06, 2013, 07:09:17 AM »
By Martin Gräßlin (graesslin) 5 June 2013 (Martin’s Blog From the land of wobbly windows)

New KWin Scripting Feature in 4.11

Go here for more details
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Ivan Cukic - Jun 8 2013

Writing a KWin effect in CoffeeScript

If you realize you don’t like JavaScript as much as everybody around you seems to, but still want to write a platform-independent KWin scripts or effects, you can try out its most promising alternative – CoffeeScript

The code below creates a KWin effect that fades and zooms in the windows when a user switches the activities.

Code: [Select]
# Martin G. likes defining variables in a namespace,
# so we are not going to make him angry -
# we are creating a namespace that has only one
# variable in it - the duration

activitySwitchEffect =
    duration: animationTime(250)

 We don't really need anything else in the namespace
# for this simple example since we are about to abuse
# lambdas (aka anonymous functions) all over the place.

# We are connecting our function to the
# currentActivityChanged signal, and processing
# all the main windows we can find

effects.currentActivityChanged.connect (activity) ->
    effects.stackingOrder.map (client) ->
        if (activity in client.activities)

            # If the client should be shown in
            # the current activity, we are starting
            # the animations - one to fade the window in
            # and another to scale it.

            animate(
                window: client
                animations: [
                    type:     Effect.Opacity
                    duration: activitySwitchEffect.duration
                    from:     0
                    to:       1
                ]
            )

            animate(
                window: client
                animations: [
                    type:     Effect.Scale
                    duration: activitySwitchEffect.duration
                    curve:    QEasingCurve.OutCubic
                    from:     0
                ]
            )

# And that's it!

Mind that this is only for demonstration – it has a few bugs in it

http://ivan.fomentgroup.org/blog/2013/06/08/writing-a-kwin-effect-in-coffeescript/
« Last Edit: June 08, 2013, 11:28:48 AM by menotu »
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline menotu

  • PCLinuxOS Tester
  • Super Villain
  • *******
  • Posts: 15515
  • ┌∩┐(◕_◕)┌∩┐
Re: Blog: KDE KWin Miscellaneous Stuff (What we did in KWin 4.11)
« Reply #28 on: Yesterday at 06:12:45 AM »
By Martin Gräßlin -  18 June 2013 (Martin’s Blog From the land of wobbly windows)

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.

http://blog.martin-graesslin.com/blog/2013/06/what-we-did-in-kwin-4-11/
PCLinuxOS 32bit KDE 4.10.4; kernel-3.4.11-pclos1.bfs & 64bit 3.4.38bfs; NVidia GeForce 8400GS 1GB 310.19 driver

Sony Vaio SVE1513A4ESI Laptop, Intel Core i5, 2.6GHz, 6GB RAM, 750GB, 15.6" Intel HD Graphics 4000

Offline Archie

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8838
  • Aurum nostrum non est aurum vulgi.
Re: Blog: KDE KWin Miscellaneous Stuff
« Reply #29 on: Yesterday at 10:04:03 PM »
Basically, the gist of the article ought to be that 4.12 will be the most important turning point of KDE SC.

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.

KWin IMO is the most important item in KDE GUI. We are good with it on Qt4. We should also start thinking about an upgrade to Qt5 if we are to slide side by side with KDE development.

Now, from the user's POV, this transition will either be opposed or accepted. First of, why fix when it's not broken would be the lamest excuse? And this will nevertheless be the foremost argument and for good valid reasons.

Qt5 and KDE SC 4.12 will be new lands to explore, and while we are content with what we are familiar with and unwilling to traverse along unfamiliar paths, I (personally) want to say that these unknown lands are the future, and it is something we need to do, whether we like it or not.

One other thing I'd like to mention in this thread is Wayland/Weston would be the future and replacement of X11.
Since 2006 | LiCo 401868 | Bare Metal | What is necessary is never unwise. --Sarek, 2258.42