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 ------------------------------------------------------------------------------ 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
