Re: [AGG] mapping swf vector description to AGG

[Timothee G. <tg...@ti...>]

Hi McSeem, 

> Ah, right, now it's much more clear. So, the data structure is tightly coupled
> with the rasterization algorithm. From the point of view of general design it's
> not a good idea because it can be hard to adapt it for use with other tools
> (suppose you have to use OpenGL as the drawing back-end).

Yes, I agree with that. Apparently, Macromedia says that they can't use
any drawing back-end such as OpenGL or DirectX to keep the player
portable to a variety of platform. So in the swf format specification,
it is mentioned that this edge representation was chosen for (I quote):

"The SWF shape architecture is designed to be compact, flexible and
rendered very quickly on the screen."


> Still, we have what
> we have and we need to handle it. I was wrong, the GPC wouldn't help much, it's
> better to extend the concept of the scanline rasterizer (keeping its basic
> functionality the same). Actually, the rasterizer works in the very same way,
> it produces a number of cells, then sorts them by Y and X, and then sweeps them
> calculating scanlines. I think if we could assign some reference ID to each
> cell (one int is enough), we could fully simulate the behaviour.

Err, you lost me there a bit. I'm not familiar enough yet with Agg and
graphic rendering in general to get this concept of cell and IDs but I
will look into that.


> The second
> thing is lines. AGG has a separate algorithm of drawing anti-aliased lines that
> works much faster than the scanline approach, see rasterizers2.cpp. I feel it
> has some potential. And the third, we'll need to write a specialized,
> "edge-based" container. We still will be able to use the pipeline converters,
> but the storage itself should be different. The existing approach is that the
> integrity of contours is preserved on the low level, for example, the contours
> are closed automatically before calculating the scanlines. In the swf the
> integrity is the responsibility of the higher level tools.

Another thing I want to ask after reading this is can we mix
simultaneously several rendering techniques in Agg? The shape format in
swf is solely based on edges. However, swf also handles raster images,
which are either placed on stage with an affine transform or used to
create bitmap fills. Also, from flash 6 upwards, Macromedia has added
some drawing API in actionscript. These are:
lineStyle
fillStyle
beginFill
moveTo
lineTo
curveTo
endFill

These API create fill/lines as path in the  "normal" way, that is, like
what Agg currently expects. I do not know whether in the flash player
these shapes are translated to the edge rendering engine or whether they
are handled differently. In fact I was very interested in Agg for that.
Right now, the drawing API only handle straight lines and quadratic
cubic curves. People have struggled to handle cubic curves from
quadratic curves in actionscript but it's tedious and slow
(http://timotheegroleau.com/Flash/articles/cubic_bezier_in_flash.htm).
If I manage to create my own flash player. I could add a lot more
capabilities here and there: map an actionscript cubicCurveTo command
straight to a curve4 call in Agg for example.


> Do I understand correctly, the engine doesn't need to calculate intersections
> between edges? Because if it should, the task becomes very complex, and
> actually turns into General Polygon Clipping. I suspect, all these calculations
> are done when creating the swf files. Is that right?

Yes that's absolutely correct, the authoring tool would have pre-
calculated all intersections. The exported edge records are the segment
in between intersections only. So rendering should be reasonably
straight-forward.

Tim