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

[Carsten Haitzler (The Rasterman)]

On Fri, 27 Feb 2009 17:16:39 +0100 Flemming Richter Mikkelsen
<quatrox at gmail.com> said:

> Once again I write about something I shouldn't
> write about at all since I don't know how it works.
> 
> I could be very, very wrong here... just guessing:
> 
> I got a feeling that no calculation (no effects)
> is faster than this "optimal code".
> 
> OM2008.0808 and earlier was quite fast and
> I think adding all kinds of effects is a step
> backward.
> 
> No eye candy means that one could play
> music, etc. when scrolling.
> 
> Do we really need illume? Why not something
> lighter with less/no visual effects, etc.?
> 
> What happened with "back to the basics"?
> 
> I don't think scalecache can make everything
> as smooth as the good old GTK theme, but
> it would be nice if I am wrong.

it's really nothng to do with the the fading effects. 3 main reasons

1. om2008 theme has a black background. drawing a solid color is half the
memory access bandwidth of drawing an image - even when not scaled.
2. it used the 16bit engine (the main main main reason for speed is this)
3. indeed icons where simple - even the label was simple text. the illume theme
just inherits from e17's default. the text here includes a soft dropshadow -
that shadowed text is draw.. believe it or not.. with 25 text draws in
addition to the text, so 26. so it actually draws 26x the text for labels
compared to the om2008 theme. the illume theme really just adds a few
elements over e17's default - which is focused on a desktop. this just saves
work for upstream to go make special themes for illume - i'm not happy with
illume anyway. it's had a lot of compromises and things done quickly to meet
requests, so until i give it some of the attention it needs to fix it up, it
isn't going to have upstream's theme really change as it is currently just on
"minimal effort' to make it work.

keep working on themes YOU want - make the ui the way YOU like. that is the
point of themes being so flexible - they can do a LOT. they alsoo have a very
big affect on performance.

N.B. the default e17 theme and illume work like a charm on more modern embedded
systems (phones as well) with more modern soc's - even with software rendering,
so the eyecandy is worth it. freerunner is just a fairly "pathological case" in
that it has incredibly low compute/draw power and a LOT of pixels to fill. if
you ask me the right design would have been something more like qvga lcd if you
changed nothing else on the device. i otherwise liken it to putting a lawnmower
engine into a ferrari body - the screen LOOKS nice, like the ferrari, but don't
expect it to go well. (it's a little extreme i know - but i'm making a point).
if you actually read the glamo specs and programming docs its very apparent it
was designed for qvga, and vga is a totally "on the limit" edge case. the soc
also is old and vga refresh uses up a significant bandwidth percentage of the
memory bandwidth available. by contrast vga uses up "almost nothing" compared
to the bandwidth available on the 6410 or even the omap3 where its pretty much
a non-event.

so don't get me wrong - it's just that you need to be realistic. the FR is a
corner-case in the device world. at least upstream dev like efl is focusing on
"whats common" not "whats out there in a strange corner". it can work - but it
needs careful tuning and attention for corner cases. so do your themes - reduce
thew workload for the renderer. a scalecache DOES help. i have checked. its
a visible difference. :) it just needs to be done so it doesnt cause
instability :) thats on my todo actually in the next few weeks.


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