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

[Jon Steinhart]

> Wednesday, May 9, 2007, 12:08:00 AM, you wrote:
> >> I really think it does. But nice rectangles are a special case.
> MG> I think he means filling solid areas as rects and then rendering the
> MG> frilly bits a line at a time
> 
> Don't get it.
> Would this method draw a circle filled with a solid color faster?

> Dunno. without hw acceleration or using some MMX/SSE variant I
> wouldn't have thought there would be that much speed increase. Maybe
> there's a speed advantage to be had in having a single x-loop filling
> several rows of pixels to the same value at each iteration.

What I really meant is that getting good performance is dependent on
understanding the whole graphics pipeline.  I'm guessing from the
traffic on the mailing list that gnash is kind of making do with a
number of existing packages, none of which are particularly optimized
for gnash.  Some improvement might be possible by choosing which
features of those packages to use.

One of the difficult trade-offs in graphics is between setup time and
run time.  When doing spans, especially short ones, it often takes
longer to set up everything needed to do the drawing than it does to
actually do the drawing.  That's one of the reasons why block drawing
can provide a big performance improvement; it amortizes the same setup
time over more drawn pixels.

My guess is that the various graphics packages that gnash is using are
overkill for flash.  Flash has a fairly simple 2 1/2 D rendering model,
and the twip thing fixes the level of anti-aliasing.  OpenGL is overkill
because flash isn't 3D, doesn't need 4x4 transforms, lighting, etc.  If
I remember correctly, a gradient fill is about the most complicated thing
in the flash graphics model.  The linear gradients are easy to do in
blocks; the radial ones are not.

Long term, it might make sense to do a gnash-optimized graphics engine.

Jon