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

[strk]

Follow ups on this:

*action_buffer*

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.

*ActionExec*

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.

*ActionHandler*

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).

*SWFHandlers*

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.

*end*

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

--strk;


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
> http://lists.gnu.org/mailman/listinfo/gnash-dev

-- 

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