Release schedule clarifications

[Frerich Raabe]

On Wed, Oct 24, 2007 at 06:13:45PM -0600 or thereabouts, Aaron J. Seigo wrote:
> On Wednesday 24 October 2007, Frerich Raabe wrote:
> > a) "Today's machines certainly have the power" - they do. However, leaving
> > aside that I'd rather prefer to keep at least 95% of the processing power
> > to my applications, the CPU usage is also annoying when it comes to laptop
> > usage (more CPU usage == more power consumption == less laptop lifetime).
> 
> when does plasma, aside from your scrollomatic wonder reader, use more than 5% 
> of the cpu for any appreciable period of time?

Hmm, then maybe I've been doing something wrong on all the computers I tested
on (1x Kubuntu, 1x FreeBSD, 1x Mac OSX, 1x Windows XP). I also tried an rsync
build from last night but didn't notice any difference, at least with the
colliding mice example.

Can somebody else maybe try this (the example is in
examples/graphicsview/collidingmice)? I always tried this on really fast
machines and except for the FreeBSD one, they all had hardware accelerated
graphics (on the Kubuntu box, my laptop, glxgears runs with ~4400fps), in
case that matters.

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).

I cannot rule out that I did a gross X server configuration problem or
something, of course. If some other people could experiment with this, that
would be great. For what it's worth, I'd expect the QGraphicsView demos (at
least the one with the colliding mice) to eat ~1% CPU, given that it merely
moves seven sprites over some pixmap background.

> > b) "The API is what counts, and it rocks. The performance fixing should be
> > left to Trolltech". I agree that the API is *sweet*, however I'd rather not
> > embarrass myself by recommending people a desktop of which I cannot even
> > say when (if at all) it will perform reasonably well. I'd rather not sit
> > there and twiddle my thumbs hoping that with The Next Release(tm) it's
> > going to be all happy happy joy joiy.
> 
> except that i've actually SEEN the improvements first hand. of course, i 
> suppose i'm amongst that "don't trust you dirty trolls" group.

Oh, I have no reason not to trust you, but I have plenty of reason to admit
that I'd rather not base my decisions on hearsay, I'd rather base them on
first hand experiences I made myself - or at least reports from a majority.
I'm sure you have access to all sorts of bleeding edge sources there, but
I'm a mere mortal, I don't :-)

> > All in all, despite the fascination when it comes to visual possibilities,
> > I'm not convinced you can build a panel & desktop & applets on QGV on X11
> > with satisfactory performance.
> 
> i'm running it here every single day with more than satisfactory performance.

Assuming that I don't have some sort of setup problem on all my machines, I'd
congratulate you on your definition of "satisfactory", I wish I could share it
:-)

> let me suggest that what you may be specifically trying to do is not prudent 
> at this point in time.

How so? I believe if there *is* a last chance to review the state of the
desktop, then it is about now. I would be fairly embarrased if KDE 4.0 came
out and did perform even more poorly than KDE 2.0; it's so easy to argue
against Plasma (and I'm sure many users might tend to do that) along the
lines "It might look sweet but my Enlightement can do the same with
0.001% resource usage!!" - people did and do that to Vista as well.

There's just one first impression you can do.

> but to say that because you can't have an 
> always-scrolling ticker in 4.0 without it using too much CPU therefore means 
> one can't have panels and what not is just ... amazingly .. i don't know what 
> the words are for it. short sighted? demonstrating an ability to only think 
> in absolutes as opposed to rationally discerning cut off points? i dunno.

I agree that saying that "you can't have an always-scrolling ticker in 4.0
without it using too much CPU therefore means one can't have panels and what
not" would be short sighted.

Luckily, neither me nor anybody else said that.

What I *did* say was that KNewsTicker porting made me realize that
QGraphicsView performs quite poorly in plenty of situations at this point,
at least in situations which occur on my desktop quite often (like, moving
something somewhere else). My computer is fast enough to handle this, but
my laptop is not. If QGraphicsView wastes cycles, and my KDE 4 desktop is
built on QGraphicsView, then that means my laptop battery won't live as long
as it could (should).

> maybe for 4.0 we just try not to have constantly moving things on the desktop? 
> to me that's pretty much just "stating the obvious"

That would be an option, but I'd rather like to avoid lowering my goals just
so that I'm able to reach them. If Plasma does not perform as expected, I
will not change my expectations, I will change Plasma. I sure hope I won't
be forced to choose this option.

> > 3.) While doing the KNewsTicker port, I noticed that (due to lack of
> > corresponding uspport in Qt), the Plasma people had to invent their own
> > Widget and Layout system (so Widget inherits LayoutItem, Plasma::Applet
> > inherits Widget and so on). This is necessary so that you can have e.g.
> > little input fields, buttons, checkboxes etc. in your Plasma applets. I
> > feel this is a gross duplication of concepts and probably a maintenance
> > nightmare.
> 
> "it's necessary ... but sucks" that sums it up nicely =)

Yep.

> > I can't shake the sensation that Plasma will not be as mature as I'd
> > expect it to be for KDE 4.0. At least, at htis point, I'm not too motivated
> > to continue developing with it.
> 
> that helps.
> 
> > Maybe it would be interesting to introduce 
> > Plasma with KDE 4.1 (after all, then it has more time to mature and it can
> > use Qt 4.4 - so real widgets and real layouts).
> 
> see my reply to Dan about this. it's equally addressed to your paragraph here.

Oh I think I am being helpful - just not to the Plasma project. I must admit
though that my primary concern is the KDE project, and not some ambitious
sub-project who seems to struggle due to some issues.

I don't accept the "Well if it sucks, then you should go and help fixing it"
line or argumentation, since to me that sounds like "We kicked something out
but failed to come up with some equivalent in time, now *you* come go and
solve this issue *we* created so that it can go live" and I don't like the
sound of that at all. :-)

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?).

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.

- Frerich