[Top][All Lists]

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

Re: [Gnash-dev] ASHandlers vs action.cpp

From: strk
Subject: Re: [Gnash-dev] ASHandlers vs action.cpp
Date: Mon, 26 Jun 2006 12:36:00 +0200

Follow ups on this:


I refactored the code so to have the 'action_buffer' being
a read-only class, and providing helper methods to read
different data types from given offsets.  The 'execute' methods
should be obsoleted: currently they are proxies toward ActioExec.
In the future, we could modify action_buffer to avoid copying
the SWF code (DoAction) blocks into memory and use the input
stream directly instead.


The 'ActionExec' class is the one used to execute
all (for frame actions) or segments (for as functions) of an action_buffer.
The Program Counter is now in the ActionExec class, which is passed by
reference to all ActionHandlers.


Currently, control flow actions need to set the ActionExec.next_pc
member rather then the PC itself. By default the next_pc member is
set by ActionExec to one-past this action offset, which is computed
before calling the specific handler (to reduce code size).


The SWFHandlers class is now a singleton, which should hide the differences
in static initialization and destructor between compilers.
Also, the _handlers table is now a vector, rather then a map.
Action id is an 8bit code so we have 255 elements in the vector and lookup
is in constant time.


The Function.swf testcase run successfully now.
We should write the above info in the gnash manual (volunteers?).
Tests welcome.


On Wed, Jun 21, 2006 at 06:03:48PM +0200, strk wrote:
> On Wed, Jun 21, 2006 at 09:11:23AM -0600, Rob Savoye wrote:
> > strk wrote:
> > 
> > > The Action handlers must have access to the
> > > program counters in a few situations and the
> > > new layout doesn't give them visibility of
> > > them.
> > 
> >   The cases were it needed to access the program counter I didn't
> > implement yet for this very reason. I mostly was just glad to move a
> > very long switch/case statement to it's own file.
> > 
> > > The cases are ActionReturn, BranchIfTrue and
> > > friends. Should we make the program counters
> > > part of the action_buffer class and pass a
> > > reference to it to SWFHandlers in addition
> > > to the reference to the as_environment ?
> > 
> >   Probably. The goal though was to fix how the PC is handled so we can
> > execute a stream while it's being loaded, instead of waiting till an
> > entire file is loaded.
> The PC should only makes sense within a single frame.
> For the streaming to work we should call advance whenever
> a NextFrame block is found in the SWF. The advance function
> would then execute the action_buffer associated with the
> current frame, which should be pretty independent from 
> the action blocks in other frames (yes, they still share
> the environment, but not a stack). At the end of each
> action_buffer execution the local stack call stack
> should be empty.
> Let me know if the above does not sound correct.
> --strk;
> _______________________________________________
> Gnash-dev mailing list
> address@hidden


 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII. 

reply via email to

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