GSoC Plasmoid Initialization

[Łukasz Olender]

W dniu 20 marca 2012 09:58 użytkownik Łukasz Olender <lukiasz at gmail.com>napisał:

> 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
>
>
Hi again. I would also like to ask who will be mentor of this project? In
KDE Ideas List is mentioned that it will be Aaron Seigo or Harald Sitter.
Are you there? It'll be better to discuss details before sending proposal.

Cheers

Lukasz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120321/2b9f1c25/attachment.html>