[moved to gnash-dev for broader audience] On Mon, Jun 25, 2007 at 11:47:10AM +0800, zou lunkai wrote: > On 6/21/07, Sandro Santilli <[EMAIL PROTECTED]> wrote: > >On Thu, Jun 21, 2007 at 08:19:55AM +0800, zou lunkai wrote: > >> Question: It seems that besides AS objects, GC also takse over more > >> general resouces, eg. SWF tags. Will this increase the scan time at > >> later collecting step? > > > >Yes, scan time will be increased by the bumber of items required to > >be marked as reachable. > >I'm just following the ref_counted layout, not adding new classes. > >Actually, I'd like to remove some classes from the ref_counted > >tree, in particular bitmap_info and character_def (and descendant). > > > >After all, a definition is always in memory anyway (in the > >CharacterDictionary) > >so it should be managed by the CharacterDictionary. The only exception is > >for dynamically created sprites (IIRC) which gets a definition created at > >runtime > >and the drawable for drawing API, which is again a definition breaking the > >documentation for a character_def (an "immutable" definition of a > >character element). > >We used a shape_character_def to avoid changing the interfaces to the > >backend renderer > >but I've always noted we had a problem there, suggesting we'd always > >render *instances* > >instead of *definitions*. > > > >--strk; > > > Currently, DynamicShape is derived from shape_character_def. And this > relationship make shape_character_def to be mutable. What about > construct the following hiberarchy, to accept both mutable and > immutalbe definitons and avoid updating all renderers(a big job I > guess)? > > shape_character_def > | > |----------------------------| > swf_character_def dynamic_character_def > (immutable) (mutable) > > Mm..., still need lots of work? Actually I don't have a clear map.
Well, this hierarchy could be better handled at the top-level (character_def, swf_character_def, dynamic_character_def). But I'd still like the "render an instance, not a character" more. --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
