plasma on mobile devices

Mobile/UMPC stuff is on my mind today for a few reasons: Summer of Code candidates have shown up on the panel-devel mailing list proposing to work on mobile projects (huzzah!); I was contacted by two different vendors today about getting Plasma on their devices; I had that recurring dream again where I'm stuck inside an Apple Newton ... crying. ;)

I noted in the Containments blog entry yesterday that Plasma is designed to be rather flexible in it's presentation. One of the (several) reasons for this has been to allow Plasma to travel to devices that aren't laptops or desktop computers: televisions, media center devices, ultra-mobile PCs (UMPCs such as the EEE PC, Classmate, OLPC, etc) and even plain mobile devices... without requiring one to start totally from scratch.

Where are we right now with Plasma on mobile devices? Well, first the good news: it works. ;) Here is a video of Plasma running on an OpenMoko handheld from back in December of '07. Getting it compiled and on the phone was the work of Marijn Kruisselbrink.

It's pretty impressive given that it was pre-4.0 code running on a mere 266Mhz of FPU-less ARM processor with 128MB of RAM and no hardware graphics acceleration. This is anything but a powerful setup by today's standards; newer OpenMoko devices are rather more muscled and things like the OLPC (let alone the EEE PC) blow it away in terms of performance.

And that's where the not-so-good news starts: from a bare start it takes ~40s to load up. Some of that is going to be library loading, but a lot of it is going to be plasma itself. Once it's up, though, it's not too bad. So what can we do about the load time?

In the video you can see how the exact same widgets and Containments we ship as part of the KDE4 desktop workspace are being used. Code reuse and ubiquity! =) This makes the performance rather impressive given that it uses all the plugins that were built for full sized, modern machines. The wallpaper file it loads is not small, the Animator is not designed for small devices and none of the utility dialogs are designed to be used in that small of a space (or at least not those fonts). It's a sort of worst case scenario, really. The toolbox works nicely there, though. ;)

So one obvious avenue of improvement is to write a Containment that is designed for the phone, e.g. something with a lot simpler wallpaper management and skipping the desktop icon loading code entirely. By whittling away at the DefaultDesktop containment one could get to something much smaller code-wise and that executes far fewer instructions during startup.

At the very least one could provide a wallpaper that matches the screen resolution, even if you kept the DefaultDesktop containment as-is.

Mod'ing the Containment alone would probably shave most of the ~9s it took to show the desktop containment in that screencast, meaning in theory we'd be down to the low 30's. Admitedly still not great.

Since it's a phone, we could probably get rid of the traditional desktop panel as well. Or at the very least create one that doesn't render a complex SVG and load the default set of desktop-appropriate applets. The panel appeared to take another 3-4s to load, so if we dropped it entirely in favour of a single Containment (aping more traditional phone interfaces) we could erase that too.

Other tricks would include an SVG theme for the phone that was simpler (and so faster to load). We don't have an on-disk pixmap cache for Plasma::Theme either, which would allow us to skip the whole SVG-rendering-storm-on-load thing as well by providing a populated cache.

Cutting back on the number and nature of default applets would also probably help somewhat, e.g. not using the rather complex kickoff launcher UI.

These are all things that occur to me off the top of my head before we even get to the work of actually profiling and improving libplasma itself. It may even make sense to whittle away at the plasma binary itself which probably has a number of desktop appropriate things that we don't care about (like the dashboard); it's only 914 lines of code, but there's likely to be some savings even there to be had.

So there is a lot of low hanging fruit out there, and most of it doesn't even involved touching core plasma code at all but rather coming up with device appropriate plugins and artwork. One exception would be the SVG pixmap cache, which would likely be done using KPixmapCache and involve touching the Plasma::Svg::Private::findInCache method.

Making things potentially even a bit easier: Sebastian Sauer commited a small patch (around a dozen lines or so) that makes it possible to load scripted Containments. So my "in theory scriptec Containments are possible, but probably needs a bit of patching to work" comment from yesterday is now ancient history. ;) This would allow one to implement things like new Containments in ECMA Script, which would be run using the built-in QScript interpreter. While obviously not as fast as C++ virtually all the execution time would be in the C++ libraries, and you could edit the code right on the phone (so no need to cross-compile, etc). Bonus points for not worry about crashes while working on these things. Given that the Tiger script example is four lines of ECMA Script, one could imaging a ECMA Script containment being about that size as well ... even with the desktop toolbox retained. We're talking about some serious development time savings here.

With the webkit ScriptEngine, one could even use HTML+JavaScript to render various screen presentations on the phone ... hmm.. haven't I heard about something like that somewhere already? ;)

So I'm happy to see that our work thus far translates to even rather modest (by today's standards) systems with acceptable results: For one, it works, even with no tweaking to the default desktop targeted plugin suite it works albeit with rough edges. I can only imagine what it will be like once we get some more people actively working on optimizing plasma for these kinds of devices, and I really hope we get at least one of the plasma-on-mobile SoC projects going =)