Concep 0.5, mockup #1

[Jakob Kummerow]

> Seriously: the use of layes and timedynamics is not done for fun but the
> limits of screenspace and the human brain.

Well, if there's an existing implementation that shows all of the
"current song" info at once, and you propose a mockup for a new UI
that only shows them one at a time, then you *are* doing it for fun
(or maybe for design), and usability suffers IMO. So I don't like that
part of your proposal.

Limits of screen space? The days of 15" CRTs that prefer 800x600
because any higher setting would flicker too much are over. Even
netbooks have more resolution than that, and 24" FullHD LCDs are cheap
as chips.
And don't even mention smartphones now - /they/ have completely
different requirements anyway.

I agree that hiding stuff makes for a cleaner appearance, and one
might prefer that when looking at a mockup/screenshot. But from my
point of view, a clean look isn't the most important thing for a UI.
(The cleanest possible UI for a computer would be just a uniformly
colored background, with maybe one large button on it that does
"everything". But guess what? All of us choose to have several windows
with hundreds of buttons, menus, icons on top of that, because it
improves our workflow.) So there must obviously be a compromise, and
the point I'm trying to make is that I think your mockup hides too
much stuff.

> That's not entirely true as the acceptable speed is usually not determined by
> your reading skills (unless you're incredibly slow) but rather your taste for
> calmness.
> Anything below 3 or 4 seconds can be assumed to be annoying.
> Now if one picked a 5 second stillness you'd have to wait 10 seconds in this
> and worst case (two iterations, third is what you want to see) or 11 to read
> everything.

I don't care what you determine an acceptable speed by or how
acceptable you think the calculated worst case would be - fact is, /I/
don't like that kind of display, and I even explained why. You're free
to have your own, differing opinion; just be aware that I for one
don't share it.

> First off: your amarok CPU abuse is likely triggered by the gstreamer phonon
> backend.

Nope, xine-backend here. Always was.

Amarok's CPU usage changes, maybe because I'm running the git version,
maybe because of other effects; I don't pay particularly much
attention to it because I've got other things to do. Today it's
between 2% and 5%, which is OK, but I've seen 20% or even more on
other days. Anyway, since it's mostly a background app, I want it to
be lightweight.

> Second: frankly, that's a matter of implementation.
> If the window is unmapped the painting should in best case consume excatly
> /NO/ cpu cycles
> (Permanent animations can be stopped, you get an event on the unmap. This
> should be done if the repaint does much more than just using some simple
> QPainter calls)

Go ahead then, submit a patch :-)

> As you mention that amarok apparently already has flaws in this regard (though
> i blame gstreamer), the 4-6 frames (on limited space) in 5 seconds an auto
> animation adds (given you don't run an analyzer) won't kill you at all.

So just because it's bad already means we're free to make it a bit worse?

> Instead one should profile and walk through the code and check for the
> performance lacks (e.g. a transparent itemview causes more cpu usage on
> repaints than a solid one, any alphachannel containing element is bad if you
> don't have usable xrender support, because the default X11 SW fallbabck is...
> improvable.

That might be one reason for sub-optimal performance in my case:
open-source radeon driver with an R600 card, so no 3d acceleration but
desktop compositing enabled (I like some transparency).
OTOH, it's not the X server's or kwin's CPU usage I was talking about,
but Amarok's own.

Cheers
Jakob