GUI responsiveness (was Re: SHR first impression : it's slow ?)

[Joel Newkirk]

On Thu, 26 Feb 2009 11:31:43 +0100
Helge Hafting <helge.hafting at hist.no> wrote:

> Joel Newkirk wrote:
> > On Wed, 25 Feb 2009 12:43:59 +0100
> > Helge Hafting <helge.hafting at hist.no> wrote:
> > 
> >> Joel Newkirk wrote:
> > 
> [...]
> > As I said, I'm guessing, but when I removed the extra PNG images and
> > leav just one, enlightenment average CPU drops and the display is
> > more responsive. The glass button effect /is/ applied to every icon,
> > it's just that the parts ('parts' in edc syntax) relevant to the
> > effect are flagged as non-visible by default.  I'm assuming that
> > even when a
> 
> Urrgh - such inefficient coding. Making a 'movie' per icon - every
> time 
> - and just not showing it for most of them. :-( The sane way is to
> only do the _needed_ calculations. Either animate a single icon when
> the effect is actually used, or generate all the frames once and just
> store them till needed. I wonder how they come up with such stuff.
> This is not only a problem on weak processors - it wastes energy on
> the good ones as well. :-(

Well as I said, I don't know to what degree and in what fashions this
may be optimized within E - I'm assuming that it prescales and doesn't
scale on the fly, but that the scrolling needs to take all visible and
non-visible parts into account - I don't know this however, I'm
guessing.

> Maybe we ought to use a modified duke nukem as an app launcher
> interface instead of enlightenment. Duke has a _better_ framerate for
> scrolling and zooming - in 3D!
> 
> Shoot at icons to start apps. Fire at the process list to kill. kill
> -9 using a bigger gun.  ;-)

:) Thanks, and to BillK for the enlightening and entertaining link. :)
With my car broken down this morning, any amusement is welcome.

> [...]
> >   Wonderful feature
> > to have, but I suspect that the calculations involved in this
> > scaling and other nice effects E offers are at least a slight
> > detriment to the (integer) FR user experience...
> >
> I wish people though more about efficiency. One can have all sorts of
> wonderful effects by precomouting some stuff _once_, and then use
> plain bit block transfers. 1990 game machines was weaker than the FR,
> but that did not seem to be a problem then.

My philosophy has always been colored by my time with the Amiga.  I
'grew up' believing that clever hardware and clever software could
overcome limited horsepower, and that the immediacy of feedback
provided by a responsive GUI is often worth more than a doubled clock.
(at 7mhz it 'felt' as fast as some 3ghz beasts I've used, simply
because everything was tweaked for smooth consistent responsiveness)
 
> [...]
> > If you watch an icon closely when you press your stylus against it,
> > you can usually perceive the fade-in taking place, particularly if
> > your FR is straining, in which case you can sometimes see a few
> > distinct delayed steps.  The linear transition is set to occur in
> > 0.2 seconds fading in, and 0.1 seconds fading out - so it is quite
> > brief.  I believe it abides by the "Framerate" setting in Illume
> > config (the spanner), such that a 30fps setting and a 0.2 second
> > fade equal a 6-frame animation.
> 
> I have now set the framerate to its minimum of 5, and turned off
> animations where I could. At least the keyboard appears more quickly
> now.
> 
> Icon animation and only two icons - selected and
> unselected.

What has me concerned on this front, looking more long-term, is that OM
have exhibited a tremendous reluctance to make the Illume/Enlightenment
config accessible, so that changing framerate and disabling animations
of windows opening, Top Shelf opening/closing, etc are currently not
possible for a new owner 'out of the box'.  Hopefully that'll be
addressed before the platform reaches more mainstream (read:
non-hacker) customers...  And not by simply disabling such features,
though that might be preferable to enabled and unconfigurable.

> > Thanks for the encouragement. :)  It's already improved my user
> > experience, but in my poking about I've broken things as well,
> > which is why I'm not offering the .edj to anyone yet.  I plan to
> > start from a clean extraction from illume.edj and default.edj once
> > more, applying only the changes confirmed to be beneficial and not
> > cause E to segfault.
> 
> Great!
> I hope this will go into the distributions, at least as a selectable 
> alternative. Eye candy is nice - but only as long as it doesn't
> create performance problems.
> 
> Scrolling is slow enough even if I grab the iconless corner - so that
> no icon actually change state. (None was selected, none became
> selected) But of course it is still slow if all those icons have to
> be scaled 9 times or so before drawing the screen.

Still guessing, but I expect the scaling only takes place once.

> > But at the pace I'm going that'll be a couple weeks still.
> > Hopefully at that point I'll be able to offer tarball and ipk
> > versions of the theme for both enlightenment in general and for
> > elementary (shr-dialer and kin, paroli, Raster's alarm, shr-config,
> > etc all use elementary) as
> 
> Take your time. Ideally, a beta release whenever one more performance 
> killer is chopped off. If it isn't too much extra work.
> [...]

I'll try to get it viable by Monday.  Not complete, by a long shot, but
usable across the board.

> > /*
> > below are lines 14053 through 14438 of 'default.edc', inside
> > 'default.edj', this copy extracted from FSO M5 IIRC but I believe
> > the same utilized in SHR. At the top it specifies what images are
> > required for this 'group', which defines a single icon on the
> > desktop. (Illume in our case) It also uses 'pager_base2.png' which
> > is defined in a global images stanza.  
> > */
> 
> Scary stuff. An interpreted language just for the icon set.
> 
> When I try to impress people with the FR, I show them cool apps like 
> linball. Not the icon interface. It is not that hot anyway - and 
> slowness is simply bad.
> 
> Helge Hafting

Be fair: The interpreted language Embryo (based on Small, recently
evolved but I forget the new name) is there for use throughout Edje.
It's used for interactions between backend and GUI, as well as to
perform other actions like triggering animations or updating clock
displays. Partly thanks to that, Edje is able to isolate GUI from
application to such a degree that the clock on the FR can be analog or
digital, or anything else desired, without any programmatic changes to
the clock module. My little hack a while back to add a call timer to
the SHR in-call GUI is a good example - done with a single 'part' added
to the theme, and a short Embryo script to update the text in
that part every second.

The flexibility and power provided by a compact interpreted language
dedicated to 'theming' is wonderful, we just need more careful choices
of where and to what degree processor-intensive features are used.

j