On Mon, 02 Mar 2009 11:44:12 +0100 Helge Hafting <helge.haft...@hist.no> 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) ras...@rasterman.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community