Plasma Quick Redux

There were a few questions on my blog entry about Plasma Quick, and before I move on to discussing Contour I'd like to quickly address them here.

What About The Desktop?

More and more components used on the desktop will be written in QML. It's simply an easier and more designer-friendly way of achieving the results we have been aiming for. However, we will not be engaging in a re-write of the desktop shell in QML. In fact, it's quite likely that plasma-desktop will remain using QGraphicsView (via a support library that will ship alongside libplasma2, if all goes well) and that the usage of OpenGL, compositing, etc. will not change in the foreseeable future. The plasma-desktop shell works, we have more pressing things to do than break it. ;)

So while the desktop will benefit from the work we're doing in Plasma Active, it won't be hugely changed by it. We will also continue to refine and add features and increase the stability and performance of plasma-desktop. This is about expanding our scope, not shifting it.

How Can This Run On Small Devices?

People often get confused when they see a device that is quite a bit lighter in terms of resources than their desktop system happily running a Plasma based interface. The reason for this is easy: the desktop shell has a lot of requirements, such as a complex task bar and large wallpapers, that we just don't face on mobile.

In Platform 4.6, you can also compile libplasma without a variety of library support, such as KDE Webkit (falls back to plain QtWebKit), KNewStuff, Solid, KIO, etc. On the desktop building it this way would be a travesty, but on mobile devices where these library may not bring any benefit, we can trim them away. We plan on increasing this kind of modularization across KDE's libraries.

In combination, this allows us to make mobile interfaces smaller, footprint-wise.

Is OpenGL Going To Work Reliably?

As with footprint, people often use the state of the desktop world as a reference point when pondering how something like extensive use of OpenGL is going to work on a given device. This is highly misleading.

The graphics stack on F/OSS as used on laptops and desktops is not in the best of places. Running composited desktops sometimes works beautifully, sometimes doesn't work at all, sometimes sorta-kinda works ... it's a mixed bag. Why the variance? Simply because there are so many combinations of hardware and software, not all of which are equally supported and/or tested.

In the device world, it's a completely different story. The hardware and the software stack are, in the out-of-the-box configuration, both completely defined by the vendor. The idea is simple: pick a bit of hardware that meets the needs of performance and power usage, ensure there's a reliable driver for that specific piece of hardware. When the variables of "which card?", "which kernel?", "which driver version?", "how is it configured?" are removed, it's possible to get a device which performs reliably.

The desktop experience can thus not be compared with any meaning. Due to this, we do not provide fall-backs to non-composited environments. This lets us trim more code, decrease testing requirements and generally focus more on a single experience rather than a chameleonlike one.

How Can Interpreted Be Faster Than Natively Compiled?

It can't; at least not if you take the same code verbatim and run it through an interpreter and compare it to an identical but compiled to native machine code version. This, however, is not what we're doing. There are two reasons why moving to QML can and will improve the experience.

QML gives us a fundamentally different way of describing a user interface. Due to that difference, the painting can be handled very differently. So it isn't the same code at all, but very different code with very different results. More on this in a bit, however.

The most important thing to keep in mind is that very little time is spent in the QML or Javascript code. The overwhelming bulk of executed code is good ol' C++ compiled natively. The heavy lifting is done in C++, the light bits, such as describing the user interface or defining how the data is connected to the interface, go into the top layer of QML and Javascript. It hardly matters if the code responsible for 1% of the execution time is twice is slow. ;)

That said, there is ongoing work to optimize both the Javascript interpreter (part of the WebKit project) and QML itself, both of which are producing promising results. So a situation that is already just fine may get even better.

Why Not Make QPainter Use This Scenegraph?

As I mentioned earlier, QML provides a fundamentally different way of describing a user interface (declarative) compared to the traditional (imperative) Qt painting system. The important difference is that the scene graph needs full control over the painting and be able to know when something is going to paint, where it will paint and how. QML allows the scene graph access to this information. In contrast, the traditional Qt painting system puts the application code in the driver's seat and, as a result, there is only so much that can be gained by using OpenGL to render a QPainter based interface.

The different approach of QML allows a different kind of approach to rendering the interface that is well suited to a scene graph rendered on the GPU as much as possible. While the traditional painting system is just fine for traditional applications, driving visually appealing interfaces with multiple animations and transitions, particularly on low power hardware, requires something like QML to perform as well as possible.

Hope that answers some of the questions :)