gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] Character definitions design


From: Sandro Santilli
Subject: Re: [Gnash-dev] Character definitions design
Date: Tue, 26 Jun 2007 16:08:45 +0200

On Tue, Jun 26, 2007 at 10:33:42AM +0200, Udo Giacomozzi wrote:
> Hello Sandro,
> 
> Monday, June 25, 2007, 10:45:29 PM, you wrote:
> >> >After all, a definition is always in memory anyway (in the
> >> >CharacterDictionary)
> 
> What about externally loaded movies ( loadMovie() )? Shouldn't the
> definition be removed when that movie is unloaded? In that case
> definitions would still need the GC or be at least ref-counted.

Yes, this is a possibility. Currently it would NOT be removed as it's
still found in the MovieLibrary (create_library_movie).

> SS> Well, this hierarchy could be better handled at the top-level
> SS> (character_def, swf_character_def, dynamic_character_def).
> SS> But I'd still like the "render an instance, not a character" more.
> 
> This would mean duplicating much code or a big redesign. As said, the
> triangulating render handlers (OpenGL) need to convert the Flash
> shapes to a simple triangles mesh. This mesh is stored in the
> character *definition* because it is unrelated to matrix
> transformations.
> 
> Moving the mesh data to the *instance* would mean re-calculating the
> same data for each instance (overkill for non-dynamic shapes). The
> (yet unused) renderer cache (which is part of the *definition*) could
> be a solution for this but that's not much different than the current
> design.
> 
> For AGG it wouldn't be such a big deal as it accesses the original
> flash shapes and the source of these shapes could be abstracted. At
> the other hand it probably will make caching/optimizations more
> difficult later.
> 
> In any case, the triangulating code and data is deeply nested with the
> character definitions, so it's hard to change this.

Maybe we can just change the *documentation* of a character_def then :)
I simply dislike the dox saying that a definition is immutable.
A whole set of bad assumption could derive from it. Think about the caches
or meshes becoming invalid when the definition changes.

--strk;




reply via email to

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