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

Helge Hafting helge.hafting at
Mon Mar 2 11:44:12 CET 2009

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.

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.

[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?

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.

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

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

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

Helge Hafting

More information about the community mailing list