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

[Udo Giacomozzi]

Hello strk,

Wednesday, September 20, 2006, 3:24:40 PM, you wrote:
s> Ok, I see what you mean about not moving the display() part
s> in the renderer, still we can move it into instances, rather
s> then definitions. What you call a MovieClip is a sprite_instance, which
s> derive from character. The definition is a sprite_definition, which
s> (should) derive from character_def.

Agree. Oddly the display() method of shape_character_def asks the
instance for the transformation matrix. The instance pointer is passed
as a parameter to the display method. Quite strange...


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

Agree (provided that these is a _interface for each _def).

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

Agree. It would have some advantages because it allows the renderer
what things to place in the cache. Don't know this yet, but maybe I
can cache the result of the AGG's own tesselator (of course having
a completely different type), which could improve performance.

However it's important that the cache items are accessed very, very
quickly. What would you say if we reserve a "cache" field in the
character instance that is completely under control of the renderer?
After all it needs to know (because of the cache) which character it
currently renders and there would be no faster thing.

At the other hand this leads to a distributed cache and the renderer
cannot walk over the complete cache to prune unused entries. But he
could do that while rendering........ ?

Are there any C++ tricks that could be helpful?


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

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

You mean, when the same, untransformed sprite is used multiple times
in a scene? Or for example font letters? Ok, that could really be an
issue.

However, when the cache is controlled by the renderer, the problem
would go away. When the cache is distributed (like above) then it
would be probably best to place the cache items in the *definition*.

Let's say we have three sprites of the same kind on the stage. The
first *instance* calls the renderer class so that it's "path" is
drawn. The renderer does so and creates a mesh set, places that set
along with transformation information in the *definition*. Now the
second *instance* does the same but the renderer notices that it has
already done most of the job for that combination of character
definition and transformation. So it skips the tesselator part and
immediately draws the rectangles. Same for instance #3.

The renderer could even take advantage of bitmap caches (potentially
extreme performance boost).

See this demo at
http://antigrain.com/stuff/particle_demo2.exe
(apparently only a Windows version available). You see the difference
when *activating* the bitmap cache...


s> (did you note the .gsc failures?).

Uhm. What's that?


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

Well, I'd say it's (it will be) up to the renderer to do that
correctly. Anyway, I don't think it's something to bother about now
since it is completely unrelated to the way the drawing API is
implemented.

Udo