gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] gnash ChangeLog server/parser/movie_def_impl.cpp [gna


From: Sandro Santilli
Subject: Re: [Gnash-commit] gnash ChangeLog server/parser/movie_def_impl.cpp [gnash_0_8_3_branch]
Date: Thu, 15 May 2008 20:03:36 +0200

Just to remind you this is an old issue we looked at, with proposal and 
discussion
here: http://wiki.gnashdev.org/MovieAdvancement

--strk;

On Thu, May 15, 2008 at 07:24:06PM +0200, Udo Giacomozzi wrote:
> Hello Benjamin,
> 
> Thursday, May 15, 2008, 6:32:01 PM, you wrote:
> 
> BW> 
> http://www.craftymind.com/2008/04/18/updated-elastic-racetrack-for-flash-9-and-avm2/
> 
> Great article, thanks for the link.
> 
> However, what it suggests is that we should redesign our core model,
> which shouldn't be difficult. We already knew that the player can
> skip frames and that it can process mouse/keyboard events quickly
> even with low fps but now we know how that works exactly. Basically
> we need a main loop at a *fixed*, compiled frame rate and check what
> action (user/invalidate/render) should be taken.
> 
> However, this doesn't mean that the desired frame rate is limited to
> a value like 84 - that doesn't make sense. That is an implicit limit
> coming from the described slices. The player still "advances" at up
> to 120 fps (ie. onEnterFrame is called that often - verified) but
> doesn't *render* at that rate.
> 
> Limiting the nominal fps rate is the wrong way - we should implement
> these slices instead.
> 
> The set_invalidated() mechanism will work skipping rendering for some
> frames as long as clear_invalidated() is only called after a frame
> has effectively been rendered.
> 
> BTW, the slice interval should be defined at runtime, via
> configuration, so that it can be configured to best match the
> hardware capabilities.
> 
> Udo

-- 

 ()   ASCII Ribbon Campaign
 /\   Keep it simple! 





reply via email to

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