Randa Meetings 2012: The Future of QGraphicsView in Plasma

I’m on my way back from the Randa Meetings, where a few teams in KDE came together to collaborate on the next steps in their respective subprojects. I’ll post this to my blog after arrival, but as I’ve got some time to kill here in Basel, Switzerland, close to the German border, I decided to recap what we’ve been up to in the past days. I’ll concentrate on what the Plasma team has been working on. Present were Marco, Aaron, Afiestas, Giorgos, Antonis and myself. Giorgos and Antonis are still relatively new to the Plasma team, they concentrate on on making Plasmate rock, but have also done some excellent work this week on libplasma2. I’m happy to see the influx of enthusiast and skilled new developers in the team, as that reduces the busnumber and makes it easier to achieve our audacious goals.

Peak up to the glacier from Randa
Speaking of goals, we came to Randa with the plan to achieve a critical mass towards libplasma2. But what is libplasma2 exactly? Well, while we had some plans where to go with it, there were still a few items unclear — but not anymore! One of the big ticket items was the future of QGraphicsView in Plasma. QGraphicsView had been introduced in Qt 4.1. It’s basically a canvas on steroids, that gained features to create a fluid, widget-based UI using it. In Qt4, QtQuick uses QGraphicsView as its rendering backend. QGraphicsView is heavily based on QPainter, and employs a procedural way to rendering the UI. In Qt5 and QtQuick2, graphical display is supposed to move to an OpenGL scenegraph, making it possible to move much of the work involved to display a UI into hardware, so your GPU can do its magic with your UI. The benefit for the user is mainly that we’re able to have a much better performing rendering engine underneath (so smoother graphics), and more CPU time left to do the real work of your application. (One side effect will likely also be that we save a bit of power on mobile devices, as the GPU is much more efficient in doing these tasks – it has been optimized for it. (Experts say that the saving is in the range of an order of magnitude. Wether or not it will be noticeable to the user in the end, we’ll have to see later.)

As the OpenGL-scenegraph-based rendering is an entirely different paradigm compared to the procedural QGraphicsView, we have to rethink our use of QGraphicsView. Unfortunately, QGraphicsView is deeply ingrained into Plasma’s architecture. Even more unfortunate is that it’s not as bugfree as we’d like it to be, in fact much of the occasional rendering glitches you sometimes see in Plasma-based UIs are caused by QGraphicsView problems. Moving away from QGV and towards scenegraph is likely to solve this whole class of problems.

So one thing is clear, we want to move towards scenegraph. But what about all the old, QGraphicsView-based code? Well, we already started moving components of Plasma Desktop one by one to QML. This has begun with Plasma Workspaces 4.8, a lot more has moved in the 4.9 cycle, and yet another batch will move with 4.10, which will be released in January 2013. Our credo has been that we want to ship feature-equivalent ports, in order to keep the impact for the user as minimal as possible. There will be a point, however, when we will have to remove support for QGraphicsView in libplasma, and that will likely be libplasma2. We expect this work to take still more than a year, so also third party developers get ample time to move their code to the (much nicer) QML way of doing UI. But why not keep support for QGraphicsView? Well, it’s not that easy, as scenegraph and QGV are due to their respective paradigms more or less mutually exclusive. We’ve spent quite some time trying to come up with solutions that guarantee maximum amount of backwards compatibility, but we also had to ask ourselves if we have the manpower to implement and maintain workarounds for the incompatibilities between scenegraph and QGV. Moreover, what would the impact on our APIs and our code be? the tradeoffs were quite horrific, so in the end we decided to bite the bullet, and remove QGV from the frameworks5 branch. But what will Plasma2 with out QGraphicsView become? What we came up with is actually a very neat and clean approach: Our classes that currently manage the workspace (Corona, Containment, Applet) will become abstract managers that concert how components work together. Containments and Applets will have their UI written in QML (so we can do the rendering in the scenegraph, thus in the graphics hardware). They are extensible through C++ and various scripting languages that have bindings for Qt. This way, you can choose to implement the business logic in your favourite procedural language (C++, Python, Ruby, QtScript, etc.) and do the UI in a declarative way. Things like theming, localization, distribution, and all that will still be offered by the platform.

Clouds descending into Randa

In Marco’s preliminary branch, where he removed support for QGraphicsView from libplasma2, the result is quite spectacular. The library is already about 30% smaller, and will likely lose another big chunk of code. That means more maintainability, a smaller memory and disk footprint and faster startup. As the functionality of QGraphicsView is more or less a subset of what we can do with QML, it’s not any less powerful or flexible. Just smaller, leaner and meaner (and also a bit easier to grok for developers using our APIs).

As you can see, we have been quite productive during this year’s sprint in Randa, and the above is only one part of what we’ve worked on. We’ve also made quite a dent into our TODO list for the KDE Frameworks 5 port, reviewed lots of patches, fixed bugs left and right, made existing code faster, and caught up with each other on various side projects. This all would not have been possible without the sponsors of the event, and the 287 people who donated through our fundraiser campaign to make this great event in a scenic location possible. Thank you all!

11 thoughts on “Randa Meetings 2012: The Future of QGraphicsView in Plasma

  1. Sounds good, but the only part that scares me in there is the statement “Graphics View isn’t as bugfree as we’d like it to be”. My immediate thought was: and you think the scenegraph is gonna be any better?
    For all I know QQ2 is still far away from being stable and performing well in the general case (ie outside their reference platform and simple use cases), and more scary is the fact that it doesn’t really have a development team anymore.
    It doesn’t mean you won’t get there, but it’s definitely not going to be a smooth ride, and it may come with its share of disappointments for example when it comes to net performance gains.

    Just my $.02 :)

    1. The bugs I’m talking about are mainly in the layouting and sizing code, so they’re bugs in QGraphicsWidgets usually, those are being removed from libplasma2. So far we’ve seen very good results whenever we replaced QGraphicsWidget-based UI with QML, so I’m very optimistic.

    2. QML2 does have a development team (3 people still working on it @ Qt afaik) and it’s already rather performant on a variety of chipsets. go look on youtube for various examples; the live coding on raspberry pie (not the reference platform) is pretty spectacular.

      will it be a 100% perfect solution? no, nothing ever is. but it already looks better than QGV which truly does not have a devel team and which has long standing bugs in rather basic things like mouse interaction (due to how mouse input handling is managed in the scene with QGraphicsWidget) that are not going to get fixed (due to no devel team and due to how they relate to the design). there are also inherent performance limitations to things like QGraphicsProxyWidget which we rely on heavily right now since it routes through QWidget classes; it is literally not possible to get instantiation of a single QGPW below 50ms on my laptop here due to the code paths it takes. this is a design limitation which QML removes from us.

      and since QMl2 is still being developed, we can meaningfully contribute to it.

      but hey … maybe you’ve done a bunch of work with QML2 and have a diferent experience? if so, please share it with us :)

    3. QML lost its (surprisingly small) Australian dev team, but the scenegraph folks have always been in Oslo iirc. And regardless I’m not worried about the ability of Lars Knoll’s team to pick up maintenance for the stuff done previously in Australia.

  2. The photographed scenery is magical. I’ts cool for our coders to work there… If the next sprint takes place in an abandon castle in transylvania, even I, a greek, will donate for it!

  3. But doesn’t that mean the widgets using the openGL scenegraph to require 3d drivers or S/W rendering and will be slower than the QGraphicsWidget if no 3d is available

    1. Well, in the worst case, widgets fall back to CPU rendering (through llvmpipe), which is what we’re doing now. I expect a not worse-than-now worst-case-scenario.

      1. Yeah, but well this would make KDE 3d only (or requiring 3d acceleration), as we will need for quasi standard plasmoids, the start menu will require it, the taskbar, the clock (?!), they are all plasmoids and as they are rewritten in QML. Kwin will also have QML window decorations…
        llvmpipe breaks multiseat technologies, even a quad cpu goes almost down with 3 gnome-shell desktops rendered.
        Will KDE also break any possible multiseat setup ( I know GPU offloading is in future xrandr, but e.g if no 3d GPU is available, only diplaylink) and have the same requirements like gnome-shell?

        1. I can’t really say, this is too far in the future, and I’m lacking the insight into these things to comment in a meaningful way. Do not that we’re still quite some time away from this ideal world. Do keep in mind that GNOME is very different from KDE’s architecture, so if it doesn’t work well in GNOME, doesn’t mean it’ll break with Plasma. We’ve seen that multiple times in the past (just keep in mind KWin’s fallback mode to “2d rendering”).

Comments are closed.