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

Carsten Haitzler (The Rasterman) raster at
Mon Mar 2 14:44:01 CET 2009

On Mon, 02 Mar 2009 11:44:12 +0100 Helge Hafting <helge.hafting at> said:

> Carsten Haitzler (The Rasterman) wrote:
> > i really suggest you have a better look at the code. it uses timepoints.
> Good advice. Critic based on assumptions isn't good enough.
> Still, the problem remain. The user interface is a bit on the slow side. 
> And it doesn't have to - simplified themes are faster.

remember you are just getting e's default upstream theme - it actually works
just fine on the more modern devices i have (omap3, 6410 etc.) and looks nice
to boot. i am not going to go to a lot of extra work by doing a specially
trimmed down theme for the gta02 when i also have other more modern platforms
to support across many devices and i want to keep my work down. as the default
works - i'm leaving it tat that :)

> Eye candy is nice - but not when it cause performance problems. eye 
> candy is also nice for showing off a great product - but this backfires 
> when it demonstrates slowness.

reality is reality here. it is a slow device. it is open though. but it's slow.
i'm not OM's marketing department. :) i'm not here to try make the freerunner
look better than it is - i have a level playing field for everything targetted
- they all get the same. :)

> [enlightenment graphichs explanation deleted]
> >> 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.
> Well, it was a joke. Duke gets much speed from low resolution.
> Still - it raises questions. Do we want the resolution, 16bpp, alpha 
> blend and so on?

it looks good in screenshots. you have a 16bpp screen like it or not anyway.
duke render in 8bpp then expands to 16bpp - evas actualyl does the harder.
renders in 32bpp and goes down to 16. you can get speed by building without
dithering on - or use line dithering that is as fast as none, but offer some
level of dither. not good for artificial images, but ok for photos. better than
no dither.

> I happen to like the high resolution and color depth. So perhaps 
> scrolling cannot go really fast in my case, and instead must to big 
> jumps to keep up with finger speed. It'd still be nice if it was more 
> responsive - scrolling start noticeably later than the dragging.

there is always a lag - also notice there is an explicit lag too - there is a
minimum amount of finger movement before it considers it a scroll. this is just
due to the nature of inaccurate finger input.

> > 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. 
> > 
> Good to hear! Even more to look forward to in future distribution 
> upgrades. :-)
> [...]
> >> 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
> Right, wasting too much memory is not the way to go either.

yup. so this stuff always comes with a big gotcha. use mroe ram, so also now
use cpu caches less effectively, and possibly pay a price of cycling the scale
caches too often thus negating the benefit. so as such i just have not done it
to date as it simply has not turned out an "on average win".

> > 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.
> Yes, I understand this is hard to do in the general case.
> The application launcher's icon collection is a specific case though. 
> The icons seem to be static, and they can be scaled once. (Actually, 
> whenever the user resets the icon size or install more apps.)

yes. for specific cases it can be a win. this is one. but i never have had the
time to get to it - i was distracted by many other things.

> > 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.
> > 
> [...]
> >> 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. 
> Seems this code is really good then - what is needed is a theme that 
> doesn't stress it too much. Even really good code needs some time to 
> execute on a limited device.

as such u'll see the themes almost never execute it anyway - it's not much of
an issue.

> > 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 :)
> Some people understand about the openness, and ability to run just about 
> any free software on the thing. Others simply want to see what's so 
> great about this phone - it is then interesting to show something they 
> don't have on their high-end nokia or whatever. :-)

well to be honest - the FR is just not a device u;'d use to impress. its open.
that's great. but it is NOT impressive hardware-wise. simply isn't. you can't
get away from that fact. you either tone down the gfx and make it
duller/blander and get speed, or u make your screenshots look better and pay a
price in speed. maybe you just change behavior to scroll less and "page" (jump
by 80% of the screen to a new page).

as i said - some of these are fixed. some are already better, some not. but
there is a lot u can do just to make the theme simpler. the 16bit enigne is
also faster. lots of config options there. personally i think the 16bit engine
output looks horrid.  but i'm fussy as all hell. also remember illume default
upstream config is GENERIC for device - its not just for the gta02. many modern
devices to 32bpp - in fact both of my current 2 active platforms are 32bpp.
thats all i use them in. so the default is definitely better a 32bit software
engine (*that can go down to 8bpp or lower even by down-conversion from 32bpp).

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

More information about the community mailing list