[Top][All Lists]

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

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

From: Jon Steinhart
Subject: Re: Re[4]: [Gnash-dev] opengl->agg?
Date: Tue, 08 May 2007 10:42:06 -0700

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


reply via email to

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