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

[Udo Giacomozzi]

Hello Jon,

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

There is a significant difference between the AGG backend and the
others. Non-AGG backends (based on render_handler_tri) indeed have a
lot of setup time to translate Flash shapes (curves, edges with two
sides, unclosed paths, ...) to traditional triangles, who can be
rendered by any graphics engine. For example, OpenGL can't deal with
Flash data structures. 

AGG, on the other side, has a special rasterizer built-in which is
designed specifically for Flash data structures. So the "only" setup
time is applying matrix transformations to vector data. Very similar
data structures are fed to AGG and it renders it all in one pass.

Note the Flash data structures are already heavily optimized for the
rendering process. They take time to understand and seem odd at first,
but are very renderer-friendly.


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

True, but this does not seem to be a real issue. Fonts for example are
drawn like regular, solid-filled shapes. Assuming correct invalidated
bounds, a small text field updating it's contents continuously is fast
as hell (100 fps and more). And this indeed has lots of setup work to
do and only few pixels to assign.


JS> My guess is that the various graphics packages that gnash is using are
JS> overkill for flash.

Overkill: Yes, they offer much more than we need, but I don't see a
problem here.


JS> Flash has a fairly simple 2 1/2 D rendering model,
JS> and the twip thing fixes the level of anti-aliasing.  OpenGL is overkill
JS> because flash isn't 3D, doesn't need 4x4 transforms, lighting, etc.

Who says that OpenGL can be used only for 3D? AFAIK Flash also takes
advantage of graphics acceleration, where available.

Anyway, I see hardware accel. support a big advantage of Gnash. Like
playing a YouTube video at fullscreen with near-zero CPU usage.


JS> If
JS> I remember correctly, a gradient fill is about the most complicated thing
JS> in the flash graphics model.  The linear gradients are easy to do in
JS> blocks; the radial ones are not.

For non-AGG backends they are pre-computed bitmaps (1x256 for linear
fills, 64x64 pixels for radial fills) and thus are like a bitmap fill
(and done quickly with hardware support).

AGG has special, heavily optimised classes for any kind of gradient
fills (including focal gradients). Still see nothing difficult in
gradients.

Bitmap fills are way more CPU intensive for a software renderer.
Still, there are about 8 different implementations available (some
have better quality, some are faster).


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

Believe me, we all the voodoo stuff Maxim has put in it's AGG engine,
we won't never be any faster.

Udo