Centralization of graphical awesomeness

Carsten Haitzler (The Rasterman) raster at rasterman.com
Tue Oct 27 02:35:43 CET 2009


On Mon, 26 Oct 2009 21:43:47 +0100 Marcel <tanuva at googlemail.com> said:

> Am Montag, den 26.10.2009, 20:33 +0000 schrieb Rui Miguel Silva Seabra: 
> > On Mon, Oct 26, 2009 at 11:16:45PM +0300, Gennady Kupava wrote:
> > > > http://www.rasterman.com/files/ello-elementary-smartq5.mp4
> > > 
> > > Thank you for videos, but on high-resolution one we can see exactly same
> > > slowness as on FreeRunner - exactly! See how top bar slides out  on
> > > close of clock and button test - exacly as on my FreeRunner. Look how
> > > slow scroll is, again as on FreeRunner!
> > 
> > I thought it was pretty snappy in comparison with my FreeRunner. But then...
> > I'm with 16bit software engine, a light theme... so maybe I've even a bit
> > less peeved at the performance than you are...
> > 
> > Regardless, it's a lot better than in the FreeRunner!
> 
> Indeed - the top bar struggles a bit when the button demo with clouds
> runs in the background which seems quite logical to me, the other times
> its so smooooth.

indeed. u have 2 processes competing for cpu, competing for io and memory
bandwidth, competing for access to the xserver (a 3rd process) which is also
competing for cpu. e is very agressive at  reducing its memory footrpint. evas
and edje for example have caches to cache previously used data (fonts, images,
caches scaled versions of images, edje groups and file content indexes etc.).
it's a caching bonanza in there. the result its.. memory footprint will expand
as the caches fill. e - every N seconds (see config dialogs for what it is set
to there, but let's say 60 seconds) will flush caches. that means empty them
out to make room for other apps if they need the memory. the linxu kernel hasno
way to do caching like it does in the fs caches for userspace. ie "please use
all unused memory for caching and if any of it is needed, just throw that
memory out". that doesn't exist outside of the kernels buffer/file cache, so
you need to limit your caches yourself and reduce them whenever possible in
case someone else may need the memory. when you see hiccups like that, it's
probably because caches got flushed and things are having to be repopulated
from disk, decoded and scaled etc. again.

if you think e is so bad... look at android. everyone seems to think its the
bees knees. go use 1  or 2 "big apps" for a while, then go 'home'. and wait
30sec or so for everything to appear. home app has unloaded most of its data
or just some of it and you can wait many many many seconds for it to load it
all back up and re-init the home screen etc. this is a faster device than the
freerunner. it takes 16 seconds to come back to "working" during which it
halts, pauses and otherwise isnt usable until its loaded everything. look at:

http://www.youtube.com/watch?v=STE_bznazPU

this is a similar effect you are seeing in e - but it's only nuking its caches
not everything. it's a bit rich to complain about something other apps/gui's do
too and yet not complain about them too. the downside of not doing it is..
bigger memory footprint, or smaller caches. (p.s. not directed at you marcel,
more just to the thread in general).

fyi... e brings bonuses you don't even know you have. here is a memory
footprint comparison (no apps running) of mer's default gtk+matchbox+ etc.
tools "desktop" to e17 - they are about functionally equivalent. e is missing
wifi management, and mer is missing a bunch of config and things e has.

mer:
@  5:27AM ~ > free -m
             total       used       free     shared    buffers     cached
Mem:           110        107          2          0          5         45
-/+ buffers/cache:         57         52

e17:
@  9:45AM ~ > free -m
             total       used       free     shared    buffers     cached
Mem:           110         73         37          0          4         38
-/+ buffers/cache:         30         80

of we shut down x to see what the footprint is just before x starts:
@  4:32PM /usr/share/icons > free -m
             total       used       free     shared    buffers     cached
Mem:           110         62         48          0          7         40
-/+ buffers/cache:         14         95

so do the math. that's 16m footprint with wallpaper, icons, gfx and more, vs
43m of memory footprint. e is agressive at saving on memory. you pay a small
price for that - these blips when it has to re-fetch and populate caches.

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




More information about the community mailing list