Release schedule clarifications

[Frerich Raabe]

On Thu, Oct 25, 2007 at 11:50:32AM +0200 or thereabouts, Andreas Pakulat wrote:
> On 25.10.07 12:26:37, Frerich Raabe wrote:
> > Can somebody else maybe try this (the example is in
> > examples/graphicsview/collidingmice)?
> 
> Plasma runs quite ok over here on both my 1.4GHz Centrino and the AMD
> Athlon 1.3GHz. Both use open source drivers with no XRender and no
> Composite support. However the newsticker does increase the cpu usage
> beyond all limits, as soon as I disable that cpu-hog all is fine.

Oops, maybe you're triggerng something then which I didn't. For me, KNT
is at ~15% all the time (which is still way too much of course).

KNT basically has 20 QGraphicsView items and a 40ms QTimer which calls
moveBy( -1, 0 ) on each of the items (and usually only three or four items
are visible, the rest is clipped away). Each of the news items and each
'+++' separator item is a QGraphicsItem.

> The colliding mice example however takes about 50% cpu on the laptop
> (with Radeon Mobility 9200), with the 7 mices that are there by default.
> There's no difference between fullscreen and window'ed display though.
> It (cpu usage) also doesn't get any worse when increasing the amount of
> mices to 40, but the  moving of the mices is like slow-motion in that
> case.

Hm, then you see the same as I do.

> > As for use cases where the CPU usage goes up: it's actually any situation
> > where you repaint repeatedly. Try moving a plasma applet around your desktop
> > and watch the CPU usage (maybe this happens with plain windows as well, I
> > didn't try that). In fact, just moving the digital clock in my panel somewhere
> > else caused a spike of 5% CPU usage (a short spike though, it's not like I
> > keep dragging my clock around the pannel all day long).
> 
> Well, plasma behaves quite ok, but X11 goes through the roof while
> moving an applet, it takes about 80% CPU in that case. Moving a normal
> window (no window effects here) doesn't do that.

Then maybe moving a plasma applet is really the same scenario as with the
colliding mice demo (after all, plasma applets are QGraphicsItems as well, just
like the mice).

It doesn't help if the Plasma process itself is cool (it doesn't do so
much after al) if it calls Qt code and Qt is slow :-)

> > Again, I think we should definately have something like Plasma for KDE at
> > some point but to me (just my KNT experiences, again) it does not seem to be
> > ready for prime time at this point (and IIRC there was some sort of 'Final'
> > to be tagged on wednesday?).
> 
> You're confusing (just as I did) the KDE Platform with the workspace.
> plasma is not included in the platform, its part of the workspace and
> for that we do another beta, not an rc.

Oh, okay. I thought the plasma libraries are part of the platform too. Thanks
for clearing that up. :-)

> > So I hope you see that it is helpful to research if there's a "Plan B"
> > available which could maybe be used in case Plasma hits other problems. Not
> > to your project maybe, but to the KDE project per se.
> 
> Not unless somebody resurrects kicker and I pretty much trust Aaron that
> this won't happen in time for 4.0, given that the code has been
> unmaintained for quite some time now.

Yes, I was told that it was unmaintained. I guess Kicker & KDesktop as of
KDE 3.5.8 are in the best state, but my first simple tries to make them
build didn't work out so well. I guess it's at least a few days of work
to get that up and running for KDE 4.

Is there no alternative? Or are we stuck with what we have right now? I'm
not too happy with this 'Plasma is slow because QGV is slow and we can
just wait and hope that with Qt 4.4 everything is boing to be good'
situation. :-}

- Frerich