This week in KWin (2012, week 39)

And another week gone. Major event of course tagging of 4.9.2 and a few more bug fixes for this version. But that’s not the only work that happened. I still have a few changes under review but also merged in some further changes for the OpenGL compositor I had been working on during XDC. Nothing really special except maybe that the specific OpenGL compositors can now be referenced by an enum type which simplifies the code checking for OpenGL 1/2 specific code in the effects.


Crash Fixes

    Critical Bug Fixes

      Bug Fixes

      • 307365: Decoration broken in maximized state
        This change will be available in version 4.9.2
        Git Commit
      • 307609: Zoom effect broken in master
        This change will be available in version 4.10
        Git Commit
      • 307125: Closed Windows stay in dock apps like AWN and docky with desktop-effects enabled
        This change will be available in version 4.9.2
        Git Commit

      New Features


          5 Replies to “This week in KWin (2012, week 39)”

          1. Hi, Unreleated but I have an important question for you, since KDE 4.7.4 and onwards I cannot use blur on kwin without the system becoming unusably slow if Open Gl 2 is selected. If I add a property using driconf to kwin so that it saves this in my drirc

            kwin works fine with Open Gl 2. I have an Intel card using i915 driver.

            1. In driconf I have to add the follwing property for kwin for it too work.

              I believe they issues started with a KDE backport update on kubuntu 11.04 and since every release to 12.10 I have the problem

              Enable limited ARB_fragment_shader support” to No

          2. 1st off, this kind of “comment” does certainly rather belong into a and not into a personal blog comment (even not the KWin maintainers one)

            On topic, I frankly can’t make much out of your talk, but for that GPU simply don’t use GLSL (OpenGL 2 shaders) – the fixed function path performs much better.

            Blurring (and “accurate” scaling) will likely be slow, because MESA or the driver lies about the GPU capabilities and then enters a SW mode, ie. there’s a too strong blurring permitted, what the hardware cannot do.

          3. To be honest it works really fast when using the workaround mentioned. The problem is that by default KDE sets OpenGL 2 on and it makes it slow unless I use the workaround.

          Comments are closed.