On Sun, 2 Nov 2008 12:58:46 -0200 "Gustavo Sverzut Barbieri"
<[EMAIL PROTECTED]> babbled:

> On Sat, Nov 1, 2008 at 11:29 PM, Enlightenment SVN
> <[EMAIL PROTECTED]> wrote:
> > +/**
> > + * Retrieves the time at which the last loop stopped waiting for timeouts
> > or events
> > + *
> > + * This gets the time (since Jan 1st, 1970, 12:00AM) that the main loop
> > ceased
> > + * waiting for timouts and/or events to come in or for signals or any other
> > + * interrupt source. This should be considered a reference point fo all
> > + * time based activity that should calculate its timepoint from the return
> > + * of ecore_loop_time_get(). use this UNLESS you absolutely must get the
> > + * current actual timepoint - then use ecore_time_get(). If this is called
> > + * before any loop has ever been run, then it will call ecore_time_get()
> > for
> > + * you the first time and thus have an initial time reference.
> > + *
> > + * @return  The number of seconds since 12.00AM 1st January 1970.
> > + * @ingroup Ecore_Time_Group
> > + */
> > +EAPI double
> > +ecore_loop_time_get(void)
> > +{
> > +   if (_ecore_loop_time < 0.0) return ecore_time_get();
> > +   return _ecore_loop_time;
> > +}
> 
> if you're adding this as an optimization, really you should move the
> pre-loop check to ecore_init() and possible make ecore_loop_time_get()
> a static inline that access an extern _ecore_loop_time?

i prefer it not inline - at least now - why? it can change
content/functionality without needing a recompile. this is not to avoid a
function call- but a syscall (sure on x86 i know its a simple counter read) but
there is one other advantage - animations are more "synced" if they use the
same timepoint - ie the time at which select() stopped being idle (if this is
an animator then that should be pretty consistent). if you have 10  callbacks
and each gets the current timepoint to figure out where along some animation
path your are - they all refer to the same timepoint now. thats the really good
bit :) but sure - can add it to ecore_init for setup too :)


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [EMAIL PROTECTED]


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to