Re: Re[4]: [Gnash-dev] opengl->agg?

[Jon Steinhart]

> Tuesday, May 8, 2007, 6:56:28 PM, you wrote:
> MG> A good distinction; I assume most of that is just running at control
> MG> rate though.
> 
> Yes, only complex graphics (lots of edges) will slow things down.
> 
> MG> Ultimately just filling in screen area is the killer I
> MG> should think, or at least hope :)
> 
> Filling with a solid color should not be the killer. AGG basically
> works like this:
> 
> As most graphics libs, it works using scanlines (threats each Y
> coordinate separately and renders that line in one pass).
> 
> It looks for all X coordinates crossing that scanline and loads a
> "span". That are the pixels between one X coordinate and the other.
> For a solid color it knows that it can de some memset stuff (or
> similar).
> 
> For all other fills (gradient, bitmap) there are special "span
> allocators" that return the pixels required to render this part of the
> scanline. Anti-aliasing is applied afterwards.

Sorry that I don't have time to be more useful on this, but a few comments
from an lifetime earlier in which I did graphics.

There are modifications to span processing that make it much more efficient.
A major improvement is to allow "blocks", where a block spans multiple scan
lines.  A span is a degenerate one-pixel high block.

Just about all graphics processors and even software implementations can fill
blocks very quickly.  The problem with doing it a line at a time is that the
setup time dwarfs the drawing time.

I don't know anything about the internal structure of gnash, but if it's
filling rectangles a line at a time performance improvement shouldn't be
too difficult.

Jon