Foreword
This is the first in five daily blog entries about the various tracks in the Plasma Active initiative. Figuring out which order to present each of the tracks was an interesting exercise. In the end, I decided to start from the middle and work our way out to the "edges". Also, keep in mind while reading each of these blog entries that all of the individual tracks are happening in parallel, and working towards a common end point!
Without further ado, I give you ...
Plasma Now
The Plasma library was designed to provide a generic construction kit for user interfaces made up of a "shell" (e.g. plasma-desktop or the Plasma KPart) and individual, interchangeable components we have come to know and love by the name of "Plasmoids". The idea has been to lower the cost of creating new primary interfaces while simultaneously increasing the amount of code, both at the data and the user interface level, that can be shared. A strong separation between visualization and data is encouraged right at the API level and has been a big part of achieving these goals.
With an emphasis on components and data separation it was only natural to explore writing components in non-compiled languages such as Javascript, Ruby and Python. In KDE Platform 4.6.0, Plasma gained support for QML, Qt's declarative interface language, as well as the ability to have device-specific interfaces in the same package. (Side note: Microsoft recently announced they were going to do exactly the same thing: one package, multiple interfaces. If device vendors had been using Plasma, they'd had that feature as early as last year.)
This is Plasma today. Plasma Quick aims to take what we've learned and accomplished and push it up a notch.
Plasma Quick
The Plasma Quick initiative aims to take libplasma, which is the underlying infrastructure for Plasma based applications, and make it an even better solution for devices that it already is. The focus points are simple:
- Performance
- Stability
- Device spectrum thinking
- Innovative user interaction patterns
The work done in Plasma Quick will inevitably also improve the desktop and netbook offerings (hooray for code re-use!), but the focus is squarely on the goals of Plasma Active: extending KDE's offerings for consumer devices. The result will be "libplasma2".
The "Quick" in Plasma Quick
In Platform 4.6 and newer, Plasma supports writing components in QtQuick's QML. One tantalizing thing QML holds out is using an OpenGL accelerated scene graph for all rendering. Having seen this in action, the results are impressive. To put it mildly. Think "better performance on a mobile device than on the typical desktop running the QGraphicsView equivalent". To get to the point that Plasma can use this scene graph, however, we need to have everything in a given shell done in QML.
This implies not using QGraphicsView. What we are planning to do is to put the QGraphicsView implementation in a second support library so that we aren't forced to rewrite plasma-desktop, plasma-overlay (aka Widgets-on-Screensaver) and plasma-netbook or the hundreds of Plasmoids people have written. libplasma2 will then rely on ScriptEngines for things like QML (as it currently already does) and allow us to write QML-only shells (as Plasma Tablet and Mobile already are) and take advantage of the OpenGL scene graph wherever we can.
Additionally, by promoting QML+Javascript to the top of the preferences stack of Plasmoid implementation languages, we will further encourage the division of labor between interface designer and software developer while making it faster to come up with fluid, modern interfaces that scale between devices.
A Whole Lotta Details
We've been collecting notes on the various changes we wish to make in libplasma2. There are a lot of details to take care of and therefore a lot of work. The first big in-person discussion and coordinated development push on libplasma2 will happen at the end of this month at Tokamak 5. Between now and then, we are continuing to collect stories and prepare things for the work to come.
If you look at the libplasma2 wiki page, you may notice that there's very little talk of new API (what we have is working pretty well, after all) and instead a lot of talk of improving what is there. Things like making DataEngine implicitly shared so that we stop passing around pointers and start passing around references or merging the various Package classes. These are the sorts of things that usually come to light only after extensive usage; these are the details that become evident after the broader strokes are laid down and well tested.
There is a lot of low-hanging fruit in there, and once libplasma2 opens up (probably later this month) there will be all sorts of great "junior level" jobs.
Newness, Too!
We'll also be introducing some new interaction patterns, including one I'll be blogging about next week that we've taken to referring to as "SLC". (Can you guess what those letters might stand for? ;) These won't be added directly to libplasma2, but be offered as components and D-Bus services. So there will also be some "new shiny" in the Plasma Quick track as well.
Somewhat Unsexy, But Unstoppable .. Like a Freight Train
We're well aware, however, that the Plasma Quick track is mostly "unsexy" plumbing work. And we like it that way. We want to improve this bit of "middleware" so that it improves as a construction kit for shells and an app creation platform. We don't feel the need to shake the whole world up at this level in the stack, however. There will be enough of that elsewhere. Plasma Quick's purpose in life is to make the exciting work happening in the other tracks possible and easier.
As can be seen in the roadmap picture above we're aiming for 7 milestones in Plasma Quick. The first will be an early release and announcement of "SLC". The second will be our work at Tokamak5 where the Plasma developer community will lay out a firm roadmap for libplasma2 implementation work. Further milestones will be time based cyclical releases. I expect the first couple to be a bit longer (e.g. ~3 weeks) as we move some big pieces into place, such as the separation of Plasma QGraphicsView, and then we'll move into higher gear and sync up with Contour with 2 week development windows as we work on things like QtComponents for Plasma, SLC, etc.
The goal is to have a well tested and tight libplasma2 ready for the auspicious October 9th date, or "9.10.11".
How You Can Get Involved
If you'd like to be a part of the next big iteration in libplasma, check out the code in kdelibs/plasma and kde-runtime/plasma. Join the plasma-devel mailing list, visit us in #plasma on irc.freenode.net and introduce yourself. (We don't bite, promise! :) Read the libplsama2 wiki page. Then start tossing your questions, thoughts and ideas around. There are no wrong questions or bad ideas; we do challenge ourselves to come up with the best ideas we can as a group, and we do that by examining the ideas we all offer with great scrutiny.
Bring your spirit of adventure, your positivity and your get-stuff-done attitude. This is a track for software developers who want to do exciting things that lie "just under the covers".
Tomorrow: Contour
Tomorrow, I'll be writing about Contour. In fact, there will be two others writing about it as well, including one of the interface designers in the project which will give us all an opportunity to "meet" her. This is a track that combines software development, interaction design, graphic art and writing, so it offers more opportunities for participation relative to the more traditional software project that is Plasma Quick. This is also the first of the Truly Exciting(tm) tracks in Plasma Active for end users.
Until then ... keep Plasmating! ;)
16 comments:
I cannot get how can be interpreted stuff (QML, javascript etc) be faster than compiled one?
What's about old machines with broken OpenGL support? Btw, on which version of OpenGL it will depend on (1.x? 2.x? 3.x? OpenGL ES?)
What's about memory usage? Right now: "The process plasma-desktop (with pid 5877) is using approximately 44.9 MB of memory. It is using 36.5 MB privately, 648.0 KB for pixmaps, and a further 24.6 MB that is, or could be, shared with other programs." and I'm worry that memory usage would only increase. How can I run plasma on mobile phone with 128-256mb ram? Will there be some kind of compile time choices like "don't build features X, Y, Z"?
Great. We Plasma GSoC students will have more junior jobs on plasma to get started before start coding the project :)
what it's usually not clear is that in QML everything that needs to be really fast, like painting or animations is *NOT* interpreted but managed by the c++ classes on the QML framework.
right now the bottleneck is painting (that will never be managed in javascript, that's for sure). with scene graph this will go away to be managed by the video card.
as memory usage, it has a growt curve comparable to any other qgraphicsview based framework, and of course all depends on how much stuff is loaded.
on a mobile, there will be of course just a fraction of the classes instantiated compared to the desktop, just because there won't be a thousand of widget around the screen, there won't be an huge wallpaper since the screen resolution is smaller and so on.
and yes, some features can be disabled compile time already and this modularization will just increase
You should make a post talking about QML. It's still unclear for me what will be interpreted and what compiled:(
>what it's usually not clear is that in QML everything that needs to be really fast, like painting or animations is *NOT* interpreted but managed by the c++ classes on the QML framework.
I'm maybe wrong, but i'm trying to compare current state of afair with future one: right now logic and painting and animations are compiled, in plasma active (as I understand) it would logic is interpreted, painting and animations are compiled. Why would there be a perfomance boost? If it's because of OpenGL rendering, why not to move Qt core painting stuff and get boost over all desktop applications?
Other question is about styling: QML and QtGui has different and independent styles, right and why? That's somewhat inconsistent.
The speed improvement will not come from something being interpreted.
The improvement will come from the graphics system - the new scene graph compared to the current QGV.
(being hardware-accelerated is not the only benefit)
You can search the net for qml, scene graph and similar for more details.
Does this mean KDE is going the way of gnome and forcing people to have hardware accelerated desktops and if not they are sent to a fallback mode?
I am a bit confused here. I would hate to have to install the nvidia driver just to get a properly working desktop.
Great stuff aseigo !!
:) i have used your layout.js to create my own panels with gnome-style
http://forum.kde.org/viewtopic.php?f=67&t=94534
it seems gnome users like it :)
:) thank you for your work
Peace- on irc
I want to insist on something hate-engine asked, which openGL version is required for the scenegraph to run?
I also wanted to check if I understood correctly: libplasma will be the fallback for systems that cannot take advantage of the scenegraph, is that correct? If so, will libplasma still be maintained and improved?
@Ivan Čukić
I meant that interpreting always has worse performance that native execution. If problem in graphics, why it would be fixed only for small amount of stuff and not for desktop in general?
@hate-engine: For QML based apps the switch from QGraphicsView (rendered by CPU) to scenegraph (OpenGL, therefore rendered by GPU) will be smooth (ideally just a runtime switch). However, for the QWidget world there can't be a magical 'switch' because OpenGL conflicts somewhat with the imperative style QWidgets are written in. That's because the imperative style QPainter (the class used to draw things in QWidget, and behind the scenes also in QGraphicsView), still let the CPU do a lot of work, killing all the boost you get with using OpenGL on the GPU.
Again, that has very little to do with interpreting vs compiling. Just that QML as an interpreted language makes it soooo much easier to write slick UIs, while SceneGraph makes effects in your slick UI then soooo much faster :)
@josericardo: From http://labs.qt.nokia.com/2010/05/18/a-qt-scenegraph/ :
"The graph is written to target OpenGL 2.0 or OpenGL ES 2.0 exclusively. We did this because OpenGL (ES) 2.0 is available pretty much everywhere and it provides the right set of features."
Does this mean KDE is going the way of gnome and forcing people to have hardware accelerated desktops and if not they are sent to a fallback mode?
@AhmedG
When it comes right down to it, you need to use the right tool for the job. There is nothing better at graphics than the graphics chips which were designed from the ground up to handle this kind of stuff.
With both AMD Fusion and nvidia Ion making their way into low cost netbooks, one can expect the majority of people to have some kind of hardware graphics acceleration.
In the coming years, we're not going to see the same kind of crippled Intel graphics chips we have in years past.
As far as drivers not being up to snuff, that's not something that should be allowed to hold a display environment back. Just because your hammer is a little raggedy doesn't mean you should be hammering your nails with a screwdriver. GPUs are far more efficient at doing graphics work than CPUs are.
If problem in graphics, why it would be fixed only for small amount of stuff and not for desktop in general?
@hate-engine
You have to start somewhere.. It looks like the idea is to shoot for the low hanging fruit which are the easiest ways to get the biggest boosts in performance and along with it, the biggest boosts in user experience.
It took Canonical months to port Unity from Mutter into a Compiz plugin and they're using Compiz for 3D and Qt for 2D... I'm somewhat skeptical that KDE would be able to get their drawing libs anywhere close to Compiz's performance, but it's certainly not impossible, and it appears to me that the approach KDE is taking is a thousand times less work than porting everything into Compiz plugins.
Post a Comment