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

[Udo Giacomozzi]

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