Release schedule clarifications

[Aaron J. Seigo]

On Thursday 25 October 2007, Frerich Raabe wrote:
> On Wed, Oct 24, 2007 at 06:13:45PM -0600 or thereabouts, Aaron J. Seigo 
wrote:
> > On Wednesday 24 October 2007, Frerich Raabe wrote:
> 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.

colliding mice sucks in current Qt, yes. fixes for that particular use case 
(running sprites all around uncached) is coming, as in "it's been written"

but here's two really interesting points:

- right now in plasma we don't run sprites around constantly
- we've implemented QGraphicsItem paint caching which fixes the things that we 
must support well substantially

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

draging a rather large digital clock applet all around the desktop for 10-15s 
results in plasma taking .3% cpu, and x.org taking 5-8%. doing the same with 
a dolphin window of comparable size results in x.org taking 15% of my cpu.

now, i'll add that right now the wallpaper painting in plasma is dismal: it 
re-blits the WHOLE desktop paper on each repaint when it's pulled from an svg 
(as it currently is even though the wallpaper is a bit map ... for whatever 
screwed up reason, but it wasn't my idea =) so this is nearly a worst case 
scenario situation, really.

compounding that issue that it uses the QPixmapCache for the background, when 
it really shouldn't.

now ... THAT said ... in general actual use, my cpu sits at 0% unless i'm 
doing something. iow, in idle ...plasma idles. when using the menu, checking 
the time, using the (needing much work) taskbar ... etc... all the things i 
do on a constant basis plasma is very well behaved.

btw, right now kwin is unusable for me. it absolutely kills the performance of 
my kde4 session. i'm currently using xfwm4 and the difference is instant.

i guess what i'm saying is:

- your complaint point is bordering on a straw man because it bears little 
ressemblance to daily desktop requirements
- there is a lot of low hanging fruit i already know about *right now*
- qt 4.4 improves things further

i suppose this is why i'm a little pissed that people are talking about 
removing plasma at this point. it's not well informed discussion but guessing 
and ponderings. it's find to guess and ponder, but making recommendations 
based on that is, imho, unwise and discourteous.

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

i've already dealt with this one in detail. why do you keep bringing it up? 
should i keep repeating the same answers in return? will it do any good? do 
you want answers or is it just that much fun to watch me chase my own tail?

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

fine. i hope you have the personal grace to revisit this once the improvements 
i've told you about appear in snapshots or on labs and add this to your 
reasons to try my 'hearsay' a bit more in the future.

(btw, 'hearsay' is when someone testifies to what someone else told them, 
literaly "saying what you heard". testifying based on what you personally saw 
and/or experienced is not 'hearsay'. i'm not giving you hearsay. it is 
significant to me that that still isn't good enough for you.)

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

holy language barrier batman. let me try again, this time being less polite 
and more straightforward:

if you can't get a constantly scrolling item to paint with decent performance, 
then don't do it right now. i don't have time to look at your code to offers 
suggestions and i also know that performance improvements are coming down the 
line. i don't think that having 4.0 not be able to show your constantly 
animated item with appropriate performance for a laptop on a battery is a 
reason to throw the baby out.

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

i don't even know where to begin with this paragraph. so i won't.

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

great, so we agree.

> Luckily, neither me nor anybody else said that.

sadly, it's exactly what it sounds like.

> 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 

none of which is meaningful performance wise. i really don't care if it 
takes .3% of my cpu in the app to move something and an additional 5% for 
x.org ... esp not when doing the same with an app window, which i do FAR FAR 
more often, takes a few times that horse power.

and to make the matter even more ABSURD .... try doing the same thing with 
kdesktop today. moving an icon around here results in kdesktop taking 4-12% 
of cpu (it jumps about) and x.org 15-30% (it jumps about too). so yeah, i'm 
sorry for making it better. with more complex objects. obviously that's a 
regression, right?

> (like, moving something somewhere else). 

man, i'm glad you didn't show up 2 months ago before we had paint caching in 
place. you would've really been horified.

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

your premise is flawed. when it comes to battery life it's what happens at 
idle that counts the most. 

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

that's totally an option for you to entertain. maybe you don't use plasma to 
4.1. if it gets these kinds of conversations to stop, i'd be grateful for 
that in fact.

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

fair enough ... your measruing of the issues is completely whacked, but i 
appreciate your sense of priorities.

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

that isn't what i said 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?).

the final is for the dev platform.

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

i would be if the research was turning up something interesting or even 
plausable.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071025/593637f6/attachment.sig>