Re[2]: [Gnash-dev] Renderer redesign

[Udo Giacomozzi]

Hello Rob,

Tuesday, October 3, 2006, 3:02:46 AM, you wrote:
RS>   Since AGG appears to have a development community of it's own, and is
RS> included on many standard Debian or Redhat derived distributions, there
RS> should be no problem with not including it with Gnash.

Ok, I didn't know this since AGG is not a .so you expect in /lib but
instead is a bunch of source code files. As long I can #include it
somehow, it's fine for me. Someone else will have to adapt the build
system - I don't know how to update config* or Makefile* for this.


RS> I'd only do this if you were making substantial changes to the AGG

None at all.


RS>   I'd prefer not to have Gnash totally dependent on AGG for internal
RS> rendering functions.

I'd use it at least for one thing: render bitmap glyphs for any
backend.


RS> We've had enough headaches with OpenGL being used in places it
RS> shouldn't be, making threading difficult.

It would just be part of the compatibility renderer base class, in one
method. And for the AGG backend, of course.


RS> If AGG has an OpenGL driver, we shouldn't need to render bitmaps
RS> ourselves, it should be handled by the driver like Cairo does.

AGG is not really comparable with Cairo. AGG does not have any
hardware interface at all and thus has no dependencies of any kind.
It's just a utility for rendering. That makes it easy to use to render
some glyphs. Cairo however is more a hardware interface. AGG will
never be able to use OpenGL or any other hardware acceleration.


RS> It may be that the AGG backend is such an improvement over the
RS> OpenGL one performance wise, that it becomes the primary backend
RS> for Gnash.

I don't know how Cairo performs with OpenGL acceleration. However I
see anti aliasing as a very important feature of a Flash player.


RS> But until it's in CVS where the rest of us can play with
RS> it, I can't really say at this time.

Maybe I can finish the redesign earlier than I thought. I keep you
informed.

Udo