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

[Udo Giacomozzi]

Hello strk,

Tuesday, September 19, 2006, 11:35:19 AM, you wrote:
s> A convenient way to write notes while stepping trough the code is
s> by using Doxygen comments

Ok, that could be the next step. However at the moment I try to make
an overview of the code...


s> Eh. For example, I don't like definitions to expose a 'display' method.
s> It should be the renderer having a display() method instead.

Ok, since we already started the discussion I attached the current
version of my notes to this mail. I hope it can be of some help - at
least being a basis for this discussion.

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.

It's the same thing how windowing systems work. You have a window,
that contains a frame which contains a label. They all have some
display() method.

The display() does actually more than just low level rendering.


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.


>> 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> Ok, so it does some sort of "optimization" for the SWF-defined shape,
s> correct ?

The tesselator is something very complex. I know what it does but
don't know how it does it as it is not documented. However, the author
states at the beginning of the tesselate.cpp file that the tesselator
is not perfect and that it does not need take care of some special
cases since the Flash IDE already simplifies shapes.


s> Maybe we won't have problems with this as the Drawing API
s> is very similar to the tags that define a shape (lineTo, moveTo, etc..)

I don't think so. Try this:

Draw a solid filled rectangle in the Flash IDE:

  +--------------------------------+
  |################################|
  |################################|
  |################################|
  |################################|
  |################################|
  +--------------------------------+



Take the top side and drag it below the bottom side making a curve.

  +                                +
  |.                              .|
  |#..                          ..#|
  |###..                      ..###|
  |#####..                  ..#####|
  |#######..              ..#######|
  +---------..----------..---------+
              ...    ...
                 ....

The left and right parts of the figure will be filled, the bottom part
won't (it has a "hole"). You will notice that the curve you just
created has been cut into three parts. You can stretch the middle part
without changing the outer parts. That means that Flash translated the
path to something that looks the same but in fact is drawn
differently. The problem is solved at design time (which can save
precious time when playing the movie).

If you draw this shape using ActionScript then the tesselator has to
deal with it. And I think this is where the various algorithms differ.
For example it could happen that the tesselator fills that hole.

A practical example would be the pentagram.


s> mm.. Note also that the Drawing API is a set of methods of the MovieClip
s> object (basically, sprites). So, we should be able to *add* lines and fills
s> to existing set of shapes (grouped into sprites). There's no concept of
s> *multiple* shape in ActionScript, it's like each MovieClip has an associated
s> *single* shape initially blank on which you can draw.

Exactly, and so it should not be difficult to implement it. lineTo()
and curveTo() would simply add items to the path and clear() would
delete it's contents. Of course each call needs to clear the cache to
make changes visible.


s> What about moving the decomposision and caching inside the renderer ?

See above...


s> Again, what about moving mesh computation inside the renderer ?
s> We might port the existing code into a specialized class which could
s> be used as it is or derived from by rendering classes.
s> The class would provide decomposition, meshing and cache.

Agree, but what about the cache? Misuse the shape objects as
containers for the renderer?


Udo

gnash-source-code-analysis (COPY).txt
Description: Text document