On Mon, 26 Oct 2009 21:43:47 +0100 Marcel <tan...@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) ras...@rasterman.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community