gnash-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-commit] [SCM] Gnash branch, master, updated. release_0_8_9_fi


From: Sandro Santilli
Subject: Re: [Gnash-commit] [SCM] Gnash branch, master, updated. release_0_8_9_final-1963-g63de409
Date: Fri, 2 May 2014 12:20:34 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, May 01, 2014 at 06:26:30PM -0600, Richard Wilbur wrote:
> On Thu, May 1, 2014 at 4:13 AM, John Gilmore <address@hidden> wrote:
> [...]
> > Gnash's problem in this area is that script code is defined to be
> > called every frame time, and other graphical actions occur then.  Gnash
> > doesn't know how to detect innocuous no-op every-frame code that
> > doesn't really need to execute every 60th of a second.  So it does a
> > lot of short poll()s and select()s and accumulates a lot of useless
> > CPU time doing nothing many times a second.
> 
> So it sounds like it would be useful to figure out how to recognize
> "innocuous no-op every-frame code" in order to make a determination of
> what to run every 60th of a second and whether we need to make the
> timeout 1s/60 = 16.667ms.

One step in that direction would be for movie_root class to expose
an interface to fetch the "next event delay" timeout. For a start it
could simply return the next 10ms boundary (the actual rate at which
heartbeat currently runs), but then it should not be too hard to
at least slightly postpone that to the FPS boundary (83ms for 12FPS
or 41ms for 24FPS) when no user intervals (or streaming media) are
present. 

--strk;



reply via email to

[Prev in Thread] Current Thread [Next in Thread]