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

[Carsten Haitzler (The Rasterman)]

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

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

i really suggest you have a better look at the code. it uses timepoints.
animation simply modifies properties of objects - doesnt RENDER at points in
time. when you begin an anim it flags things at point A. then when the next
frame "tick" rolls around it calculates whatever properties (size, position,
alpha etc.) and applies those. applying does NO rendering. all it does is set
values in data structures. small values. its very efficient. after all the coee
that is transitioning opject values finishes setting the properties - and
everything goes idle THEN it decides to draw/render - whatever the state is at
now. if the animation already completed (eg animation was set to take 0.1
second, but actually 0.2 seconds has elapsed since the start) all properties
will just instantly be set to the final state and only that rendered. 

if you want to find out how the code works ask those that wrote it. dont assume
from things you read here :) it's not making a "movie" per icon. it's simply
modifying a few parameters (maybe a grand total of 50 of them) per frame. and
then it only renders the frames it CAN render. if u set the framerate to 200fps
- it sure as hell wont calculate 200 frames per second as it will be render
limited and will only calculate what it can. the code is very smart and does
just what is needed.

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

and runs in 8bpp and doesnt alpha blend, doesnt do interpolated scaling. doesnt
do a tonne of things.

btw - scrolling issues were also a problem of the event loop in some ways and
has been fixed in the meantime - but you are unlikely to see those fixes until
fso/shr or om2008.x update. (basically it was getting and actually responding to
more mouse events than it could handle delaying rendering even more than it
should have been 0 i fixed that. it shouldnt have been doing it but somewhere
along the way a excess mouse move filter got removed and i dont know when/where
so i put one back in). it all went smooth again. 

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

as per my other mail. the reason i DIDNT do this is that there is a tradeoff -
every precompute means u have to store it. storing means using up more ram, and
using less cpu. you give up one resource for another. ALSO you need to
intelligently differentiate dynamic data vs static. lets say u have a vidoe
that changes data every frame - there is zero point in computing a scaled
version and making a copy of it to keep as next frame it will be different.
same for when the image or data keeps changing size. each frame its a new size.
again - pointless to keep a copy. its not so easy just to "precompute" it makes
coding life harder as the programmer now needs to do this in advance. you want
the api to figure it out for u and just do it by magic. as i said - i have a
patch that added a scalecache that does this, but it also introduced bugs and
thus isnt in. i havent had time ot come back to it lately - but its on my todo
list.

believe it or not evas's software engine is REALLY efficient and fast. it gets
both quality and speed. it plays some other tricks you barely even know exist.
i know about all these game engine tricks- i started life writing game engines
in assembly. i have just specifically chosen to handle certain paths for
certain reasons. and to date those paths have worked extremely well for the
workloads they were given. those paths were a LOT more dynamic with new data,
new/different sizes and much less re-use of images/.data at the same size where
caching would help.

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

again - you need to actually do your research. it's not interpreted at
all. .edc's are a data structure. they declare what becomes an in-memory
object tree with properties. they get compiled to binary .edj files that are
loaded and converted to real life objects REALLY FAST. its highly optimised.
they also cache and share instances so it only loads the 1 edje group once - it
then just references the already loaded one and makes copies runtime. it keeps
them around even when not references speculatively in case they are needed
again. the only interpreted part is embryo script {} sections. inside of that
is also not interpreted like python or perl. its bytecompiled into a very
small efficient bytecode language. its stored in the .edj as bytecode so
simply loaded up - never compiled or interpreted at runtime as you see it. the
bytecode engine is VERY fast. it's 2x the speed of the jvm. it's 40x faster than
python. 20x faster than perl or ruby. it's about 1/7th the speed of compiled C
- which is not bad considering its a bytecode vm. it's also used very rarely
in edje files - only when simple event -> response logic fails and more is
needed. 

you might seriously want to learn more about the code before you evaluate it
and poopoo it as many of the things you have assumed are just totally false
and it actually does it right or even better than almost anything else within
the same class of flexibility. :) 

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

if i want to impress i do not show them a freerunner. i show them something
with much better hardware :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com