> 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 _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
