gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] Questions about trapezoids, triangle stripper etc.


From: strk
Subject: Re: [Gnash-dev] Questions about trapezoids, triangle stripper etc.
Date: Wed, 20 Sep 2006 15:24:40 +0200

On Tue, Sep 19, 2006 at 11:38:15PM +0200, Udo Giacomozzi wrote:

> I'm not sure if I understand what you are actually trying to do but
> giving the display() method to the renderer would mean reversing the
> whole mechanism.
> 
> The display() method comes from the character_def class. Both a
> MovieClip and shapes derive from it and they know how to draw
> themselves. A MovieClip will draw it's own characters and the
> child MovieClips. Characters know how to tell the renderer
> what to draw. So the display() method of the root MC is used to call
> all display() methods recursively and after all Flash is hierarchical.

Ok, I see what you mean about not moving the display() part 
in the renderer, still we can move it into instances, rather
then definitions. What you call a MovieClip is a sprite_instance, which
derive from character. The definition is a sprite_definition, which
(should) derive from character_def.

I'd drop the display() method from character_def and leave it in
character.

> s> I think all the intermediate representation only needed for rendering
> s> should happen and be cached inside rendering classes, not character
> s> definition.
> 
> Yes, that's what I thought too at first. However that would result
> into a renderer that must organize a huge list of cache objects. To be
> efficient it would have to associate cache objects to the shape
> objects.
> 
> For example, say you have a simple movie with two sprites. Sprite A
> does never change and sprite B continuously switches between 100% and
> 200% of it's own size.
> 
> That currently results in 1 cache object for sprite A and 2 cache
> objects for sprite B (one mesh for each size factor). That's easy to
> do when the cache resides in the sprite itself. How should the
> renderer understand which cache object matches? He can't certainly
> compare all edges...
> 
> Keep in mind that there are can be thousands of shapes which need to
> be drawn in a frame.

It could be a map (possibly hashed) based on character pointer.
The advantage would be more control on the cache. For example,
a cache entry could have a time to live, or could have a size limit
(to reduce memory usage). Not sure about how much would this impact
performance though.

> >> server/parser/shape_character_def.cpp would be the place to look since
> s> Ok, so you suggest that ActionScript code actually creates "definitions"
> s> rather then "instances" ?
> 
> Uhm, are there character instances? I just know about MovieClip
> definitions/instances..

It seems that this was at least an original developer idea at a given
time. I confirm the code seems not to reflect this all over the places.
I guess the main use for it is caching definitions (immutable structures)
to files (did you note the .gsc failures?).

(removed the part about drawing api,don't really know how to proceed
there, we'd need some intersection detection functions to reorder
the lines probably).

--strk;




reply via email to

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