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

Hendrik Siedelmann hendrik.siedelmann at
Thu Feb 26 16:49:31 CET 2009

2009/2/26 Helge Hafting <helge.hafting at>:
> Joel Newkirk wrote:
>> On Wed, 25 Feb 2009 12:43:59 +0100
>> Helge Hafting <helge.hafting at> 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. :-(

Perhaps you should have alook at the efl before stating such things.
I also don't have much insight, but thats what I think I understood:
The non-visible parts shouldn't need any but size caclculations, the layering
and stuff is also reasonably fast, at least much faster than what the FR can
transfer to the screen anyway. I think the main proplem is the scaling, smooth
scaling is pretty slow, there is a scale cache planned, but not actually
finished, when it comes things will get much faster.
The efl are way faster than any other toolkit I know of, especially if you trim
down theming.

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

Well does it do alpha? And is it using the screen in 480x640 or only a quarter
the screen size?

> Shoot at icons to start apps. Fire at the process list to kill. kill -9
> using a bigger gun.  ;-)
> [...]
>>   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.
Really have a look at the EFL, very efficient.
Problem is, the Theme just needs to be optimized. And using the
16-bit engine also gives a huge speedup.
> [...]
>> 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.
If it can't cope with the high framerate it will of course simply drop frames.
And for parts it will easily hit 30 fps, that's why I leave it on default
(but disable some animations).

> Icon animation and only two icons - selected and
> unselected.
>> 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.
>> 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.
> [...]
>> /*
>> 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.
Not really, it's mainly layout and animation and you will not notice the
speed penalty as long as you don't use thousands of elements.

> 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


More information about the community mailing list