GSoC Plasmoid Initialization

[Łukasz Olender]

Hi,

I've got an idea for upcoming GSoC event. It's based on
http://community.kde.org/GSoC/2012/Ideas#Project:_Lazy.2FAsynchronous_Plasmoid_Inititalization.
It is not a finished proposal, just a draft of idea and I hope that
you
can actually help me make it better and more precise :) Also I'd be very
graceful to hear any advices about it or just comments, whatever :)

Proposal Title: Asynchronous Plasmoid Inititalization



Motivation for Proposal / Goal:

Plasma is powerful widget engine written on top of Qt libraries which is
extensively used in KDE Software Compilation. It is heart of Plasma Desktop
and Plasma Notebook workspaces which are well-known by lot of people using
Linux. Due to cross-platform nature of Qt libraries, creating and deploying
environment based on Plasma for mobile devices is also possible and is
currently realized in Plasma Active project.

All of those environments have to control a number of running Plasma
applets named Plasmoids. Currently all of those Plasmoids are initialized
in synchronous fashion using only one thread. This leads to longer startup
times than necessary, especially in modern computers running workspaces
containing a lot of them. My goal is to make Plasmoids initialize
asynchronously to reduce overall Plasma startup time.



Current Implementation Details:

Plasmoids are categorized in Containment class' objects. This class has a
private member ContainmentPrivate with method initApplets(). Inside it, a
loop invokes for each Plasmoid his initialization function. This can be
noticed in kdebug messages showed below.

plasma-desktop(2793)/libplasma Plasma::ContainmentPrivate::initApplets:
!!{} STARTUP TIME 25808319 Applet "Application Launcher"

plasma-desktop(2793)/libplasma Plasma::ContainmentPrivate::initApplets:
!!{} STARTUP TIME 25817795 Applet "Calendar"

plasma-desktop(2793)/libplasma Plasma::ContainmentPrivate::initApplets:
!!{} STARTUP TIME 25818203 Applet "Hard Disk Status"

Those messages include current time in milliseconds and it is clearly
visible that startup times of Plasmoids differ. Those times may highly
depend on code included in Plasmoid's initialization method, regardless of
programming language used to program it. Plasmoids are quite independent of
each other (at least at initialization step); there is no reason to keep
initialization in synchronous fashion.



My Implementation Idea Details:

Simply I'll start from implementing Applet::init() method asynchronously
and take care if nothing goes wrong. If something bad will happen, I will
consequently go through underlying classes and make them run in
multithreaded environment. At this time I'll have good knowledge how to
rewrite Applet and Containment classes for implementing asynchronous
signal-slot mechanism. It will be used to notify Containment object about
status of initialization.  Last thing I want to do is update rest of
Plasma's files to make all code work together without any unpleasant
surprises.

To achieve this goal I'll use classes provided by QtConcurrent namespace.
They allow invoking functions in separate threads using their own thread
pool. Amount of created threads depends on actual needs and available
processing units, so solution is flexible and will continue to scale when
deployed on multi-core systems in the future. QtConcurrent is also quite
easy to implement and understand comparing to creating and handling a lot
of QThread instances.

I am also going to use existing Plasmoid Viewer application to build simple
application which will allow me to run a number of Plasmoids in separate
environment (instead of only one in Plasmoid Viewer).

Well, what do you think about it?

Best regards,

Łukasz Olender
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120320/cd9b04d1/attachment.html>