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