[Panel-devel] PhotoFrame plasmoid, plasma performances & the Zen

[Robert Knight]

> The users will surely try to load some of their 6+
> megapixels photos, and rotate and stack them on the desktop

Perhaps scale the photo when it is first loaded and save the scaled
image in the Plasmoid's data directory.  This also solves the problem
of a photo from a remote Url which would have to be re-downloaded each
time the Plasmoid was opened.  I sort of did this as part of a patch
for the frame (see below), although I need to re-work it to keep up
with code changes that happened since I wrote it.

> So it becomes very slow when  you try to move it, or when you
> move above it another (big) plasmoid, such another photoframe.

Ouch.  Rotation probably ought to be implemented in the main
Plasma::Applet class or a delegate, instead of requiring each Plasmoid
to handle that itself.  Much like resizing and moving.  Rotation seems
to be a bit of a performance sore-point in QGraphicsView generally.
The Troll behind the magic mentioned the same problems with rotated
widgets in his blog about exciting widgets-on-a-canvas research.

> p.s. sorry for this c++ newbye question: doesn't all objects created
> with the "new" keyword must be explicitly destroyed  with "delete

Yes.  Although the QObject class has a concept of parent-child
relationships.  When a QObject is constructed, a pointer to the parent
QObject is usually passed in the constructor.  When the parent QObject
is deleted, it will delete all of its children.

A typical use of this is that when constructing a dialog for example,
various QObject-based things are created which have the dialog widget
as their parent.  When the dialog is deleted, it will automatically
delete the child QObjects without them needing to be explicitly freed
in the destructor.  I believe that QGraphicsItem works the same way
with parent / child QGraphicsItems

> Also this plamoid hangs plasma while it loads or downloads the image

I have a patch to fix this which I will adapt and commit and some
point.  At the moment the plasmoid is using the synchronous KDE IO
methods which means that the program blocks while the download is
happening.  The correct solution is to start a KJob which downloads
the data in the background and notifies the plasmoid when it is
complete.





On 09/07/07, Mercurio <mercurio at personellarete.it> wrote:
> Hello all, I'm new to KDE and Qt development: it seems Aaron's (and
> other) advertising  was very effective, after all :D
>
> I'm working to the photoframe plasmoid, and I'm concerned about its
> performances. The users will surely try to load some of their 6+
> megapixels photos, and rotate and stack them on the desktop. Currently
> the paintInterface() of this plasmoid just draws a prescaled and
> composed  pixmap of the photo: indeed it is very fast and I don't know
> how to optimize further this...
>
> but the plasmoid uses QGraphicsItem transformations for rotation, and
> when it is rotated, plasma recalculates the transformation each paint
> event. So it becomes very slow when  you try to move it, or when you
> move above it another (big) plasmoid, such another photoframe.
>
> So should I prerender the rotated picture in a pixmap (and deal with the
> coordinate mess) or use QGraphicsItems (great) facilities as much as I
> can, maybe also for scaling, and let this performance problem to plasma
> developers? ^^''
>
> Also this plamoid hangs plasma while it loads or downloads the image. It
> seems that multithreading programming will be mandatory for some
> plasmoids like this... does things get better if I try to write a
> DataEngine for loading images?
>
> Thanks for your patience.
>
> - Antonio Vinci
>
> p.s. sorry for this c++ newbye question: doesn't all objects created
> with the "new" keyword must be explicitly destroyed  with "delete", at
> least in the class destructor?  Otherwise there is a memory leak if you
> open and close many plasmoids, isn't it?
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>