On Tue, Nov 29, 2011 at 11:24 AM, David Seikel <onef...@gmail.com> wrote: > On Tue, 29 Nov 2011 05:21:21 -0500 Michael Blumenkrantz > <michael.blumenkra...@gmail.com> wrote: > >> On Tue, 29 Nov 2011 20:15:43 +1000 >> David Seikel <onef...@gmail.com> wrote: >> >> > On Tue, 29 Nov 2011 04:58:12 -0500 Michael Blumenkrantz >> > <michael.blumenkra...@gmail.com> wrote: >> > >> > > On Tue, 29 Nov 2011 19:51:26 +1000 >> > > David Seikel <onef...@gmail.com> wrote: >> > > >> > > > While I'm happy that EFL is working on the tiny little embedded >> > > > 800MHz 486 board, it might be a tad underpowered. >> > > > >> > > > At one point during this devices typical usage, it has to send >> > > > stuff to a serial printer, play a sound (through a USB based >> > > > built in sound chip), AND do a simple edje animation. At other >> > > > times, it might be doing one of the more complex animations, >> > > > but need to play a short sound on demand. The printer is kinda >> > > > fussy about the timing of stuff sent to it. >> > > > >> > > > After a short bit of testing, the sounds sometimes stutter quite >> > > > badly during the heavier animations, but is smooth during the >> > > > others. However, this is in a test mode, where there is more >> > > > stuff on the screen to slow things down. >> > > > >> > > > It's my understanding that edje runs in the idler, so shouldn't >> > > > the sound and printer, which both use ecore FD handlers to know >> > > > when it's a good time to write, have priority? >> > > > >> > > > I can probably fine tune things enough with judicious edje >> > > > freezes, or frame time, or something. It does not really >> > > > matter if the animations are a little jerky, might not even be >> > > > noticeable, but the sound and printing have to be spot on. >> > > > >> > > > Any hints from those more experienced with edge and FD handlers? >> > > > >> > > it's important to keep in mind that ANY blocking will impede >> > > execution of the main loop. fd handlers are called as soon as they >> > > are able, but select() is limited by the next timer's duration; if >> > > you have lots of timers (eg. animations) playing, select() will be >> > > available for shorter amounts of time, potentially leading to i/o >> > > starvation while timers and related functions do their work. >> > >> > Good point. >> > >> > There's only one animation timer waiting at any given moment. It's >> > all very simple sequential animations that roll along one after the >> > other, then loop. The "heavy" animation period is a 0.12 second >> > timer that triggers 8 simple edje programs (two state changes each >> > that just change visibility of small images) one every 0.12 >> > seconds. Then it goes back to the 3 and 5 second timers. This is >> > the bit that's causing the stuttering though, and I could work >> > around it more or less. >> > >> you could try to micro-optimize by combining multiple edje programs >> into scripts I suppose > > I had been thinking that it might be worthwhile to convert them into a > lua script. Should be interesting to see what impact that has on the > 486.
Edje include a cache for not computing again thing that have been computed during previous frame. This is disabled by default, but you can turn it on it help in many case as it will just recalc the animated part of an edje. It does use more memory. Maybe we will turn it on for next release. -- Cedric BAIL ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
