Posted on

And There was Text

Short update from the Wayland efforts:

This is quite a success as it took me several days to work out how to activate the window and get keyboard events to it. Now with that done I can start looking at the real window managment bits.

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

Posted on

Wie sicher ist WebGL wirklich?

WebGL erlaubt es OpenGL in Webseiten einzubetten, also 3D Grafiken auf der lokalen Hardware direkt zu rendern. WebGL baut auf der API von OpenGL ES 2.0 auf, welches selbst eine Untermenge (und Teilweise Übermenge) von OpenGL 2 ist. Eine Webseite, die WebGL einbindet, funktioniert somit prinzipiell auf aller Hardware die entweder OpenGL 2 oder OpenGL ES 2.0 unterstützt. Das ist so ziemlich jedes moderne Smartphone und auch jede Grafikkarte der letzten Jahre.

Persönlich betrachte ich WebGL als den größten Durchbruch im Web Bereich der letzten Jahre und als viel wichtiger als HTML 5. WebGL hat das Potential eine neue Ära einzuleiten. Vor allem im Bereich der Web basierten Spiele sehe ich ein unglaubliches Potential für diese Technologie. Aktuell wird für vieles immer noch Flash verwendet, was größtenteils über die CPU ineffizient rendert. Aber auch viele Webdienste wie z.B. Kartendienste können von 3D Beschleunigung profitieren.
OpenGL ist der offene Industriestandard für 3D Grafik und steht in direkter Konkurrenz zu einer proprietären API, welche nur von einem Softwarehersteller kontrolliert wird. Mit OpenGL laufen Anwendungen auf allen verfügbaren PC Plattformen, mit OpenGL ES 2.0 ist der boomende Markt der Smartphones und Tablets abgedeckt, auf dem es noch keinen konkurrierenden Standard gibt und mit WebGL betritt OpenGL erneut einen Bereich in dem es noch keinen vergleichbaren Standard gibt. Es ist erfreulich zu sehen, dass der offene Standard hier vor der Konkurrenz ist und die Technologie vorantreibt.
Sollte WebGL sich als bevorzugter Vermarktungsweg für moderne Spiele durchsetzen, wäre dies ein schwerer Schlag für die konkurrierende API und den Webbrowser des selben Herstellers, der WebGLnicht unterstützt. OpenGL Anwendungen würden ohne jegliche Anpassung auf allen verfügbaren Plattformen über den Webbrowser laufen, sämtlicher Portierungsaufwand entfällt komplett. Zusätzlich gibt es dem Hersteller der Anwendung ein bewehrtes Distributionsmedium (das Web) in die Hand.
Zuletzt hörte man einiges an Kritik bezüglich der Sicherheit von WebGL (z.B. bei fefe), vor allem möchte der Konkurrent von OpenGL, WebGL nicht in seinen Webbrowser einbauen aus Sicherheitsgründen. Die Sicherheitsproblematik läuft zusammen auf die Tatsache, dass Anwendungen aus dem Web Zugriff auf die lokale Hardware bekommen und nativen Code ausführen können. Zusätzlich gibt es auch (noch) keine Sandbox um den Code abzuschotten und da auf die Hardware zugegriffen werden kann, wird auch einiges des Codes im Kernelmode ausgeführt.
Das ist soweit natürlich alles korrekt, nur macht es die Technologie WebGL grundsätzlich nicht zu einem Sicherheitsproblem. OpenGL für sich ist eigentlich eine riesige Sandbox. OpenGL ist ein Zustandsautomat bei dem die eigentliche API nur dazu da ist den Zustand zu setzen. Also zum Beispiel eine Textur zu laden und anzugeben, dass die nächsten Zeichenbefehle diese Textur verwenden sollen. Das eigentliche Zeichnen der Geometrie erfolgt mit sogenannten Shadern. Es gibt dabei einen Vertexshader zum Umwandeln von Vertices im Anwendungskoordinatensystem nach Clipcoordinaten und den Fragmentshader um jedes vom Vertexshader bestimmte Fragment zu zeichnen. OpenGL verwendet zur Programmierung dieser zwei Shader Zustände eine eigene Programmiersprache namens OpenGL Shading Language (GLSL).
GLSL ist eine sehr domain spezifische Sprache speziell für die Anforderungen der 3D Grafikprogrammierung. Der Vertexshader bekommt als Eingabewerte Attribute pro Vertex und als Ausgabewerte liefert er variierende Werte, die an den Fragmentshader weitergegeben werden und als Eingabeparameter verwendet werden. Der Fragmentshader produziert nun einen Farbwert. Zusätzlich können beide Shader auf gemeinsamen Speicher zugreifen: auf den OpenGL Zustand über sogenannte “uniform” Werte und auf Texturen.
Die Shader in GLSL werden vom OpenGL Treiber in hardwarespezifischen Assemblercode kompiliert. Der Compiler sollte dabei sicherstellen, dass der Code nichts machen kann, was OpenGL nicht erlaubt, also z.B. auf Speicher außerhalb des Kontexts zuzugreifen. Jede Textur und auch jeder Shader wird nämlich in einem Kontext erstellt und ein Objekt darf nur auf Objekte des selben Kontexts zugreifen. Wenn der Shader vom Treiber nicht kompiliert werden kann, so wird ein Fehler zurückgeliefert auf den der Anwendungscode reagieren muss.
Die Technologie WebGL ist also selbst die Sandbox, die angeblich nicht existiert. Ein Shader kann nur graphikspezifischen Code ausführen und es wäre mir auch noch kein Fall bekannt, bei dem GPU Code auf die CPU “ausbrechen” könnte. Die einzige verbleibende Gefahr wäre somit das setzen der Zustände um den Shader auszuführen. Dabei besteht eigentlich auch kein Problem, denn OpenGL ist sehr fehlertolerant und bei einem fehlerhaften Ansprechen der API wird ein GL_ERROR zurückgeliefert was im schlimmsten Fall zu Darstellungsfehlern führt. Die OpenGL API ist somit auch Bestandteil der Sandbox.
Wie wir sehen bietet die Technologie WebGL außreichend Sicherheit. Mittels der Technologie ist es nicht möglich Schadprogramme auf den Client zu bekommen. Die Vorwürfe gegenüber der Technologie sind daher einfach falsch.
Anders sieht es mit den Implementierungen aus. In der Theorie sollte OpenGL sicher sein, jedoch kann ich aus eigener Erfahrung sagen, dass dies nicht der Fall ist. Alle Treiber (egal ob offen oder proprietär) haben Fehler und können die Anwendung zum Absturz bringen, bei legalen und illegalen OpenGL Befehlssequenzen. Somit ist ein Angriffspotential denkbar: ist man in der Lage über die richtigen Befehle in WebGL den Treiber zum Absturz zu bekommen, kann man im schlimmsten Fall Code auf der CPU ausführen. Dies ist ein reales Angriffsszenario, dessen sich die Browserhersteller bewusst sind. So hatte ein Mozilla Entwickler vor der Veröffentlichung von Firefox 4 z.B. auf der KWin Mailingliste nach den Erfahrungen zur Stabilität insbesondere der freien Treiber nachgefragt.
Von dem theorethischen Angriffsszcnario zu einem Exploit ist es dennoch ein weiter und meiner Meinung nach sehr unwahrscheinlicher Weg. Zum einen ist es schwer den OpenGL Treiber gezielt zum Absturz zu bringen, zum anderen diesen Absturz zum Angriff auszunutzen. Abstürze lassen sich nach der Erfahrung mit KWin meistens nur in einer bestimmten Kombination von OpenGL Befehlen, Treiberversion und Hardware erreichen. Ein Angreifer müsste also den Angriff speziell auf Hardware und Treiber zurechtschneiden. Natürlich wäre solch ein Fall dann eine Möglichkeit den Browser remote abstürzen zu lassen, dies ist natürlich schon einmal sehr schlecht, lässt sich aber von Browserherstellerseite sehr leicht beheben indem WebGL Kontexte in einen eigenen Prozess ausgelagert werden.
Die viel größere Schwierigkeit dürfte sein den Crash zum Angriff auszunutzen. Außer GLSL (was ja nicht auf der CPU sondern GPU ausgeführt wird) gibt es keine Codebestandteile, die direkt ausgeführt werden. Die WebGL API zum Setzen des OpenGL Zustands verwendet JavaScript und sollte somit vom restlichen System abgeschottet sein. Die API selbst erlaubt auch ausschließlich nur das Setzen der Zustände. Die einizige Möglichkeit größere Speichermengen über Buffer anzusprechen (um zum Beispiel Angriffscode abzulegen) ist das Laden von Texturen was jedoch in der WebGL API im Vergleich zur OpenGL C-API abgesichert wurde.
Falls es mittels Texturen und OpenGL API möglich ist einen Treiber so zum Absturz zu bekommen, dass Code ausgeführt werden kann, so ist das ein grundsätzliches Problem was nichts mit der Technologie WebGL zu tun hat. Moderne Webbrowser verwenden OpenGL auch zum Rendern der Canvas womit es denkbar ist, dass durch das einfache Einbinden desselben gefährlichen Bildes der Browser zum Absturz gebracht werden kann und der Schadcode ausgeführt werden kann.
Wie wir sehen ist der Vorwurf gegenüber der Technologie WebGL nicht sicher zu sein, schlicht falsch. Genaugenommen betrifft es nur sich fehlverhaltende Implementierungen deren Schwachstellen generell ausgenutzt werden können, egal ob es sich um WebGL, hardwarebeschleunigtes Rendern der HTML Canvas oder harwarebeschleunigtes Flash oder Silverlight handelt. WebGL ist hier im Vergleich zu anderen Lösungen wie hardwarebeschleunigtes Flash sogar besser, da es sich abschotten lassen kann.
Ich möchte hier nicht sagen, dass der Einsatz von WebGL ungefährlich ist. Sicherlich besteht durch die Instabilität der OpenGL Implementierungen und der recht neue Einsatz in Webbrowsern ein Gefährdung. Jedoch betrifft diese alle Technologien, die auf OpenGL (oder auch Direct3D) zugreifen. Das Argument des Konkurrenzherstellers klingt daher für mich als vorgeschoben und nach FUD um der Konkurrenz zu schaden und die konkurrierende API nicht im eigenen Webbrowser einsetzen zu müssen.

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

Posted on

Neues Spielzeug

Es sollte ja kein Geheimnis mehr sein, dass der X Server mitlerweile angezählt ist und mit Wayland der potentielle Nachfolger bereits in den Startlöchern steht. Auch wenn es noch lange dauern wird bis wir X endlich in den Ruhestand schicken können, ist für mich bereits der Zeitpunkt gekommen, mich etwas intensiver mit der neuen Technologie zu beschäftigen. Für KWin ist es wichtig früh Wayland Anwendungen zu integrieren, da man unter KDE Plasma Wayland nicht benutzen kann, wenn KWin Wayland nicht unterstützt.

Letzte Woche habe ich angefangen KWin um ein Wayland Backend zu erweitern. Glücklicherweise ist das Wayland Server Protokol extrem einfach gehalten wodurch man sehr schnell erste Ergebnisse erreichen kann:
Dieser Screenshot ist sehr interessant. Das Terminal Fenster ist ein Wayland Client, die Fensterdekoration ist jedoch ein klassisches X11 Fenster. Wir kombinieren hier also beide Technologien. Dies zeigt sehr schön die Strategie, die wir bei KDE Plasma einschlagen: schrittweise Unterstützung für Wayland Fenster implementieren ohne unseren bestehenden Desktop zu zerstören. Erst wenn wir volle Unterstützung implementiert haben, werden wir X11 verlassen und auf Wayland wechseln. Bis dorthin werden wir eine Strategie fahren bei der Wayland Clients unter X11 verwaltet und gerendert werden.
Auch wenn der Screenshot schon nach sehr viel aussieht, darf man sich nicht täuschen lassen. Bis wir auf Wayland sind, ist noch ein weiter Weg. Viel muss erst noch implementiert werden. Für mich ist das gerade extrem spannend und ich fühle mich wie ein kleines Kind mit einem neuen Spielzeug. Schritt für Schritt kann ich nun die Fenster benutzbar machen. Dabei lerne ich auch richtig viel noch über KWin Interna. Mit dem X11 Fenstermanagement musste ich mich eigentlich nie beschäftigen, da es vollständig und korrekt implementiert ist. Nun bin ich dabei Fenstermanagement für Wayland nachzuimplementieren.
Richtig toll ist wie viel einfach so ohne jegliche Anpassung funktioniert. Vor allem unser Effekt Framework interessiert sich überhaupt nicht dafür ob ein Fenster nun X11 oder Wayland ist. Es wird einfach integriert und angezeigt. Auch wie man im Screenshot sehen kann, ist es den Fensterdekorationen egal ob sie ein X oder Wayland Fenster dekorieren.
Experimentierfreudige Nutzer können das ganze auch schon testen (auch wenn es extrem langweilig ist) wenn sie selbst aus den Quellen bauen. Bis das ganze in Distributionen verfügbar wird, wird noch einiges an Zeit vergehen. Da wir ja in Feature Freeze für 4.7 gerade sind, werden all Änderungen erst in 4.8 erscheinen und auch dann ist es fraglich ob Distributionen mit den entsprechenden Build Flags bauen werden (wer hat denn schon Wayland in den Repos?). Bei OpenSUSE wird es wahrscheinlich in den Factory Builds verfügbar sein, sobald die Änderungen in den master branch einfließen. Bei Kubuntus Project Neon ist das auch denkbar, jedoch könnte die Wayland und Mesa 7.11 Abhängigkeit das ganze erschweren.

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

Posted on

Discovering a New World

This weekend a group of KDE hackers met in a small mountain village, Randa, in Switzerland to discuss the future of the KDE Frameworks. I was not present, but started on Saturday an endevour for the future of the KDE Plasma Workspaces. Yesterday evening I arrived in the new world:

desktopgrid-with-wayland
This is not just the Desktop Grid effect. The gears window you can see on each of the desktops is a Wayland client, all other windows are X clients. For me this is a rather historic event, not just for KDE but also and especially for Wayland. Up to now there have only been the demo compositor and the QtCompositor as Wayland Compositors. They are more or less just proof of concept. But this is different event: we have here a normal X11 window manager and are able to integrate Wayland clients into the compositing scene just as if it were an X client. This is not a Wayland compositor, it is a X compositor with an implemented Wayland Server component.
This is the proof that there is a sensible migration path from X11 to Wayland. We can use our normal and known X system and manage Wayland clients in it. There is no need to implement the complete stack on top of Wayland first with possible regression. As we can see the Effect Framework does not need any adjustment to support Wayland Clients, which means we can give the user their known KDE Workspace experience. For the user it is irrelevant if a window is an X or Wayland client, it is just a window. For KDE this means that we don’t need and won’t break the desktop. We will switch to Wayland when we are ready, but at the same time we can offer Wayland to interested developers and users who want to experiment with it. For Plasma Active on the other hand we will switch to an X less Wayland-powered KWin as soon as possible.
Of course there is still a long way to go to get to Wayland. This is just rendering, we still need to implement the complete Window Management, transition the compositing away from X, break out X from KWin and lots more. It’s the result of four days where I spent a few hours each day on hacking on that topic. Which shows how simple the Wayland protocol is, although the documentation could be better 😉
Now the next steps will be to clean up the code, document it and push it into a git branch. I hope to see many developers to pick up on it and to start implementing the window manager functionality and extending e.g. Plasma Desktop to support Wayland Clients in the Tasks Applet and many more such things.
I will present the complete KWin Wayland strategy at Berlin Desktop Summit in August.

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

Posted on

Guest Post: A Hello From KWin GSoC

This is a guest post by my Google Summer of Code student Arthur Arlt.

Hello everyone,

in this very first blog post in my life I first want to introduce myself. Then I 
want to give an overview on my GSoC objectives and say some words about code I 
already produced for KDE’s compositor KWin.
My name is Arthur Arlt. I am studying Applied Computer Science (MSc) at the 
University of Heidelberg. I reached my Bachelor degree at the University of 
Mannheim, where I studied Software- and Internet Technology (BSc). I still 
live in Mannheim and shuttle to the university, since all my friends live here 
and Heidelberg is not that far away (and much more expensive to live, as 
well;).
My GSoC project deals with refactoring KWin’s workspace class. In consequence 
of more than twelve years programming work this class grew to a giant 
‘monster’. Very many functionality was just added to the workspace class 
leading to a header file of almost 1500 lines of code. The objective of my GSoC 
project is to refactor this one big class, structuring the functionalities to 
reasonable own classes as modules. On the fly it is possible to rename 
variables and functions to follow a consistent naming scheme.
Doing all this is not only just for fun. The main reason for the 
modularization of KWin is to ease the port to Wayland. Also some 
functionalities are not required for special devices like tablet PCs. E.g. the 
functionality of screen edge handling is not needed for devices controlled by 
touchscreen.
In the past three month I started to code some peanuts for KWin. The first idea 
I had was to extend the quick tiling feature with tiling to quarters. My 
mentor Martin Gräßlin showed me where the changes have to take place and I got 
my first feature implemented 🙂 As a foretaste of my GSoC I moved the outline 
functionality to an own class. This made it possible to easily write an effect 
for outlining windows and replace the old X implementation.
My first GSoC step was to remove the non-working functionality of TopMenu. As 
replacement we now have Kubuntu’s AppMenu. The second step I am currently 
working on is to break out the TabBox (Alt+TAB) from workspace to an own 
class.


Cheers!

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

Posted on

The Compositing Modes of KDE Plasma Workspaces Explained

In the KDE Plasma Workspaces 4.7 we introduce new Compositing backends/modes in our Compositor. Lately I noticed that there is some misunderstanding on what are the differences between the modes, why we wrote new code and what is the best mode for whom (at least one distribution did it wrong in their first packaging approach). With this blog post I hope to shed light on the various modes.

OpenGL 2.x/GLX

This is our default compositing backend. It uses only the so-called programmable pipeline or also known as the “core” profile. For rendering we use only shaders written in the OpenGL Shading Language (GLSL) without making use of any fixed-functionality emulation code. For the interaction with the underlying graphics system we use GLX and the extensions for compositing. Namely the texture from pixmap extension to get an OpenGL texture from an XPixmap (the window content). As the code matches the core profile it would be easy to add “support” for OpenGL 3 or 4, just in case someone is wondering. But as we do not make use of anything provided by OpenGL 3, there is no need for this.

OpenGL 1.x/GLX

This is our legacy backend and the code we only had in 4.6 and before. The code uses only fixed functionality. Up to 4.6 it was possible to also use Shaders written in GLSL. This is no longer possible. Effects requering shaders may provide a shader using the ARB Shader extension which can be used only in this mode. The code to access the underlying graphics system is shared with the OpenGL 2.x backend.
The legacy backend is used automatically for all drivers not supporting at least OpenGL 2.0 and the fglrx driver. Furthermore there is an option to enforce this mode in the Advanced Desktop Effect settings: uncheck option “Use OpenGL 2 Shaders”.

OpenGL ES 2.0/EGL

This is the backend for the future. It’s primary target are mobile devices (Plasma Active), but also on the desktop it is very important as it is the requirement for supporting Wayland. Like OpenGL 2.x it uses the programmable pipeline and shaders written in GLSL. In fact the OpenGL ES 2.0 and OpenGL 2.x backend are identical to more than ~ 95 %. The difference is in the way how to access the underlying graphics system. Instead of GLX we use EGL and the EGL_KHR_image_pixmap to bind an XPixmap (window content) to an OpenGL texture.
In opposite to the other two OpenGL backends this one is not a runtime option, but a compile time option. OpenGL ES 2.0 is (mostly) a subset of OpenGL 2.0 without the legacy code. So the old code would simply not compile against the libraries and that’s why it is a compile time option. To enable use the CMake flag “KWIN_BUILD_WITH_OPENGLES”. Be aware that EGL is not supported by all drivers. To my knowledge only the Gallium radeon and nouveau drivers support it at the moment. This means especially for distributions: don’t use the build flag for the default package, but provide an additional one. For the next release cycle I hope to make it a runtime option.

XRender

XRender is a completely different backend. It can be selected in the advanced Desktop Effect settings in the dropdown “Compositing type”. Furthermore it is used as a fallback when the OpenGL backend fails in an expected way (e.g. Software Rasterizer). The XRender backend can only provide 2D animations, so e.g. no Cube effect. Performance on the backend depends on the driver, but can be rather fair (I once did not notice that the XRender backend was used in a virtual machine).

No Compositing

Not really a backend, but also a mode which has to be mentioned. KWin also supports no compositing at all. This mode can be entered at all time by the Shortcut Alt+Shift+F12 and in the General Desktop Effects settings through option “Enable desktop effects at startup”. Also at runtime self checks may disable compositing and also applications can block compositing bringing KWin into this mode. The Composited mode can be re-enabled through the same shortcut.

How To Notice which one is Used?

This can be quite tricky, because KWin automatically falls back to a different backend if one fails. E.g. if OpenGL 2 is not available OpenGL 1 is used. Or if OpenGL fails, KWin might fall back to XRender. KWin does nowhere log which backend is really used, but there are some messages printed to stdout which can help recognizing the version. KWin always prints out the used OpenGL version information. This looks for OpenGL like this:

OpenGL vendor string:                   Advanced Micro Devices, Inc.
OpenGL renderer string:                 Mesa DRI R600 (RV710 954F) 20090101 TCL DRI2
OpenGL version string:                  2.1 Mesa 7.10.2
OpenGL shading language version string: 1.20
Driver:                                 R600C
GPU class:                              R700
OpenGL version:                         2.1
GLSL version:                           1.20
Mesa version:                           7.10.2
X server version:                       1.10.1
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes

And for OpenGL ES:

OpenGL vendor string:                   X.Org
OpenGL renderer string:                 Gallium 0.4 on AMD RV710
OpenGL version string:                  OpenGL ES 2.0 Mesa 7.10.2
OpenGL shading language version string: OpenGL ES GLSL ES 1.0.16
Driver:                                 R600G
GPU class:                              R700
OpenGL version:                         2.0
GLSL version:                           1.0.16
Mesa version:                           7.10.2
X server version:                       1.10.1
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes


To distinguish OpenGL 1 from OpenGL 2 backend there is one debug message related to "KWin::ShaderManager::initShaders". There should be three messages for valid - then OpenGL 2 is used or at least one message on failure, then OpenGL 1 is used. Recognizing XRender is even more difficult. In case that we face issues for debugging we will add more precise debug messages. Personally I test which backend is used by using functionality tests: the Cube Effect requires at least OpenGL and the Sphere and Cylinder effects require at least OpenGL 2.




Why a new Backend?


There are several reasons why I started to work on the OpenGL 2/OpenGL ES 2.0 backend. First of all we wanted to have support for everything which is nowadays known as Plasma Active, but also Wayland is very important on the longer term. Currently Wayland requires an EGL backend, so having support for EGL is a prerequisite. Last but not least to give our users the best possible performance and user experience. The programmable pipeline is a way nicer API to write GL code and especially the ES code can benefit users as it throws out all the legacy code and state tracking, which is rather complex in OpenGL and should ensure better drivers.




=-=-=-=-=
Powered by Blogilo
Posted on

Plasma Compositor and Window Manager in 4.7

With the first Beta for KDE Plasma Workspaces 4.7 out of the door it is time to look back what we achieved in the last half year for the KDE Plasma Compositor and Window Manager. Personally I think this will become a very great release with hughe improvements for our users. The best about it is, that users should not even notice that anything changed at all. Almost everything we did is under the hood improving performance, stability and rendering.

Programmable Pipeline

The Compositor received a new OpenGL compositor based on OpenGL 2.x or OpenGL ES 2.0. Our default rendering nowadays uses the programmable pipeline instead of fixed functionality as in 4.6. In order to support the programmable pipeline quite some parts had to be rewritten and got optimized at the same time. Overall this brings a vast performance improvement for all users. From my experience this can even be increased when using the OpenGL ES 2.0/EGL backend which is unfortunately a compile-time switch (as not all drivers and hardware support EGL). I hope that distributions will provide an additional package.
As with all such changes there is the chance that on some hardware/driver combinations the performance decreases due to the raise of requirements to OpenGL 2. If that is the case the user can switch back to the legacy rendering mode by unchecking the option “Use OpenGL 2 Shaders” in the advanced Desktop Effects settings. This will disable all GLSL Shaders. Nevertheless Blur and Lanczos are still useable as they will fallback to ARB Shaders.

Blur Effect

Fredrik has done some great work to improve the performance of the blur effect. Effects can know recommend whether they should be enabled by default and for Intel hardware, the effect does not get enabled any more by default. Users can still manually enable the effect. But there is also some real optimization to ensure that less screen estate gets blurred in each rendered frame and some optimizations on the shader giving a ~60 % improvement in shader performance with R600G.

Blocking Compositing

Thomas worked on a way to allow applications to block compositing. The primary goal is to have video players or OpenGL Fullscreen games be able to block compositing as for such use cases compositing is only a bad overhead. We have heard interest from VLC and Wine to support this new flag, but users  can even make use of it if the application does not yet provide support for it by using a window specific rule. Given that we have now this new way to suppress compositing we disabled the unredirection of fullscreen windows by default.

New Shadows

Together with Jacopo, Hugo and Aaron we worked on adding a new Shadow system allowing to provide their own shadows. This is currently used by Oxygen Qt and GTK to render shadows for so-called unmanaged windows. As the control for the look is with the client, the widget style is able to adjust the shadows for e.g. Mozilla Firefox. Also Plasma is making use of the new Shadows for the Panel and KRunner fixing some annoying issues with the old implementation like window snapping to the panel shadow and clickable shadows in KRunner. Not to mention that the new shadows look way better 🙂 Special thanks to Jacopo for writing the XRender code for the new Shadow system.

Outline

Arthur, our GSoC student, did some refactoring already before the GSoC project and brought all outline related code together in one class. This allowed me to add a new Effect to render the outline using a nice looking Plasma FrameSvg. If effects are not active the old X11 code is used. I am looking forward to Arthur’s GSoC, what I have seen so far looks very promising.

Graphicssystem Raster

Very short before the release we received a Patch from a new contributor, Philipp, allowing KWin to support the graphicssystem raster. Before KWin enforced the native system. In the beginning I was reluctant to integrate it, but got convinced that this is a hughe improvement. Especially with the NVIDIA blob this is a nice addition as we circumvent the slow transparent filling of XPixmaps improving the performance of resizing windows (caused by decorations) and the effect frames in e.g. Present Windows effect. There are more improvments to come from Philipp like a heap optimization for glibc in KWin, scheduled for 4.8.
And of course much, much more happened which I just don’t remember at the moment 🙂 And for the next release cycle we can expect more great things to happen, more about that on Desktop Summit.

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

Posted on

Where ends the Workspace and where begins the Application?

This week there was an interesting, but too heated discussion on kde-devel about the feature or bug of dragging windows from any empty space. I don’t want to comment on the topic as I participated in the discussion and by that are biased and this is post is not about the feature but more about what we can derive from such discussions.

When we look at the thread, we can distinguish three groups of people participating:
  1. Users – they either like or dislike the behavior
  2. Application developers – they consider the behavior as a bug which breaks their application. They want the behavior either weakened or disabled by default
  3. Workspace developers – they consider the behavior as a feature provided by the workspace. It is not a bug that the window can be dragged. No application gets broken by it; in the worst case it’s an annoying, but very consistent behavior.
I would have expected a fourth group in the discussion, namely Application developers who don’t care and either like or dislike the behavior. Given that the discussion was quite heated this is not really surprising that they did not participate.
For the further discussion we do want to concentrate on the second and third group. The most interesting issue is the homogeneity of the two groups. The developers from both groups have a very clear and uniform opinion on the matter and both groups are completely disjoined. No workspace developer could accept that this is a “bug” and on the other hand no application developer could accept that it is a “feature”.
What I derive from this discussion (which also confirms what I have been thinking for a long time) is that application developers and workspace developers are different group of people with different interest. We are all united under the KDE umbrella, nevertheless applications and workspace do not always and must not always pull towards the same direction.
The workspace developers have I would say more the view on the big picture. For the workspace developer it is (to keep in the example from above) important that there is a consistent and predictable move behavior. We have eliminated the visual distinction between window decoration and window content therefore everything that is empty content has to be a target for window movement. If we look at other platforms this is quite acceptable. Examples are MacOS X or Ubuntu. The workspace defines the platform and behavior and the application has to integrate. If they don’t do they are forced by enabling such features by default.
We have seen such differences between workspace and application developers quite often lately. Other examples are the switch from Legacy Systray to StatusNotifiers. With Legacy Systray the application has control over behavior and visualisation of its icon, while with StatusNotifiers both is moved to the desktop shell. Another non-KDE example are the action-less notifications of Ubuntu. The application developer considers its notifications as important and wants actions while the workspace defines that there are no notifications so important that they should have actions on them.
To me this results in the question: Where does the workspace end, and where begins the application? What is allowed for a workspace, how far can we “break” the application?
The KDE workspaces are still very bad at providing such a unified workspace compared to our competitors. The shining examples in this area are clearly MacOS X and Ubuntu, but also GNOME is still doing a better job in that area. Lately KDE improved. This is mostly thanks to the efforts of the Oxygen team to develop a GTK+ style. Thanks to that GTK applications integrate wonderfully into our workspace from look and also behavior. Nevertheless there are still quite some blockers like the horrible file dialog (which is for me reason to not use any GTK application):
But even for the look there is still lots of work to be done. E.g. consider the following screenshot of a popular Microsoft VoIP software:
Although it is a Qt application there is no way to get it use our style and not even the Qt plattform integration kicks in. This is a clear candidate where it does not matter what the application actually wants. For the consistency which we want to provide the application has to follow what we want. If we look at other platforms we see that Skype integrates perfectly into MacOS X, so enforcing our own look’n’feel seems to be acceptable.
Another area of the workspace version application are the client side window decorations (CSD). As it’s probably known I am not a fan of CSD and see hughe advantages for classic decorations from the consistency and integration point of view. In fact I think the advantages of server side decorations are so many that a “break” of applications with CSD would also be justified. I am even considering to try the changes for 4.8. If we look at the EWMH we see that there is nowhere specified when a window should be decorated. It is up to the window manager to decide on sensible defaults. Chromium currently does not get window decorations as it uses a legacy Motif hint. In fact the EWMH clearly states that Motif is deprecated and we would be fine to remove it:

Rationale: This hint is intended to replace the MOTIF hints. One of the objections to the MOTIF hints is that they are a purely visual description of the window decoration. By describing the function of the window, the Window Manager can apply consistent decoration and behavior to windows of the same type. Possible examples of behavior include keeping dock/panels on top or allowing pinnable menus / toolbars to only be hidden when another window has focus (NextStep style).

The specification has last been updated in 2006, so yes removing legacy code is something we can think about. 

Lately there has been some discussions about Wayland and Client Side Decorations and I have been asked why I don’t participate. From the issues I presented last year, some were X11 specific, but the general consistency problem remains. Therfore I see no reason why we should start to allow broken apps. (I also think that Wayland should concentrate on providing a good architecture and leave decisions on the workspace behavior to the various workspace implementations.) And for those not understanding why I consider all applications with CSD as broken: here a nice screenshot (I only enabled window decorations from Alt+F3 menu).


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

Posted on

Bye, bye KDE 4?

Wer die OpenSource Medien gestern oder heute verfolgt hat, dürfte ja schon mitbekommen haben, dass Nokia Qt 5 für nächstes Jahr angekündigt hat. Das hat natürlich auch Auswirkungen auf KDE. Um die Neuerungen von Qt 5 verwenden zu können, müssen wir gegen die neue Version linken, wodurch unsere KDE Platform eine binär inkompatible Änderung erhält. Die Folge davon ist recht logisch: KDE Plattform 5.

Für mich ist die Ankündigung von Qt 5 und dem daraus zwangsläufig folgendem KDE Plattform 5 keine Neuigkeit, besonders mit einem KDE 5 rechne ich eigentlich seit der Planung des “Plattform 11” Sprint für die zukünftige Entwicklung der KDE Plattform. Dass nun Qt 5 kommt, ist da sehr passend. Sehr erfreulich ist auch das nun offenere Entwicklungsmodell von Qt sowie einem Qt Contributors Summit direkt nach Plattform 11. Auch bei Plasma haben wir bereits mit den Planungen begonnen mit libplasma2 und im Compositor und Window Manager planen und überarbeiten wir auch unsere APIs. Hier ist natürlich ein sich ankündigender ABI Bruch eine schöne Sache, da man besser planen kann und nicht den Bruch in der Laufzeit der KDE Plattform 4 bringen wird.
Ich persönlich freue mich auf diese neue Entwicklung, da ich bei der Entwicklung zu KDE 4 noch nicht dabei war und das eine sehr interessante Aufgabe ist. Das Designen einer guten API betrachte ich als große Kunst und eine der schönsten Disziplinen der Informatik. Daher freue ich mich darauf die Dekorations-API den modernen Anforderungen anzupassen.
Nun habe ich die ganze Zeit sehr bewusst von der “KDE Plattform” gesprochen. Die KDE-libs werden ihre Versionsnummer erhöhen, für Anwendungen und die Plasma Workspaces steht das aber noch nicht fest. Nach aktuellem (noch nicht wirklich existierendem) Planungsstand soll Qt 5 hauptsächlich neu kompilieren sein und natürlich wäre das auch für die KDE-Libs eine sehr schöne Lösung. Anwendungen und Plasma werden also einfach weiter funktionieren. Wir sind sehr zufrieden mit unserem aktuellen Stand und sehen keinen Bedarf erneut den Desktop zu brechen. Sehr schön hat auch Aaron diese Gedanken zusammengefasst. Ob das ganze dann KDE 5 heißt, weiterhin KDE 4 heißt oder einen ganz anderen Namen bekommt, ist aktuell noch völlig offen und noch nicht entschieden oder diskutiert.
Für mich ist es bei der Entwicklung – gerade auch in Hinblick auf Wayland – oberste Priorität den Desktop nicht zu brechen. Auch wenn es sich zeitlich anbieten würde mit KDE 5 auf Wayland zu setzen, werde ich solche Pläne nicht verfolgen. X11 wird für uns zumindest in nächster Zeit weiterhin eine wichtige Plattform sein.
P.S.: alle Kommentare wie fürchterlich KDE 4.0 war und dass sich sowas nie wieder wiederholen darf, werden konsequent moderiert. Das wissen wir selbst gut genug.

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

Posted on

On Stability

KWin has been known as a rock-solid window manager in the KDE 3.5 times. I was wondering how the situation is nowadays with focus no longer on window managing but on compositing. Currently we are experiencing a major problem in combination of Intel/Mesa drivers with either fullscreen flash videos or OpenGL screensavers. Since the release of Kubuntu Natty we receive two to three new duplicates each day. In case you are experiencing this issue: do not report! Neither to us, nor to Mesa nor to (K)Ubuntu. It is a known issue and Upstream is working on a fix! As a workaround, do not use Flash to watch Youtube videos and do not use OpenGL screensavers. The issue is the most often reported bug against KWin of all time, now.

The fact that we receive duplicates for an issue clearly recognized by DrKonqui as already reported multiple times can tell us a lot about other problems. If we have a real stability issue we receive many bug reports and we have seen this in the past. Apart from the noise of mentioned crash above we have hardly received any new issue lately, so I thought about going through all our crash reports to get an overview of our current stability. I am also a KWin user and cannot remember a single KWin crash at work with openSUSE 11.4.
After todays and yesterdays triaging there are less than 20 open crash reports and I am only able to reproduce one of them and fixed another one. Most of our previously open crash reports have not seen any activity over the last year(s). Many of them had been reported against 4.4 or an even older release without duplicates of newer versions. All those have been closed, given that we most likely fixed these issue. Many thanks to Thomas for fighting crashers in various effects and the window grouping functionality. (Keeping the crash reports open does not make any sense as there have been too many code changes to make any use of old crash reports.)
The remaining open issues which I am not able to reproduce are in most cases missing a description how to reproduce, so it is very unlikely that these affect our users and it is possible that they are already fixed. Given this, I am happy to say, that also as a compositor KWin is rock-solid 🙂

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