gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Renderer redesign


From: Rob Savoye
Subject: Re: [Gnash-dev] Renderer redesign
Date: Mon, 02 Oct 2006 19:02:46 -0600
User-agent: Thunderbird 1.5.0.7 (X11/20060913)

Udo Giacomozzi wrote:

> - I'd really like to see AGG to be a fixed, integral part of Gnash so
>   that it can be used to render font bitmaps for OpenGL and Cairo
>   backends.

  The usual way of handling dependencies for a project is to not have to
maintain your own branch. It looks like AGG is still under development,
so relying on the released packages is preferred. For the same reason we
don't include Boost, GtkGLExt, or any of the other development packages
that Gnash also uses. Usually another project is only included in the
source tree when you're doing alot of development on the 3rd party
package, and your sources only build and run with the included version.

  For example, for many years I released GDB with my own Tcl/Tk/Expect
sources, as it was close to impossible to get changes applied upstream.
I was forced to do this so the GDB Tk based GUI would work correctly.
This was a pain in the neck, because for years I had to track the
official Tcl/Tk releases, extract patches, and do alot of additional
work that I'd have eliminated not having my own branch. I only did this
because patches to Tcl/Tk were not accepted by the core development team
at all.

  Since AGG appears to have a development community of it's own, and is
included on many standard Debian or Redhat derived distributions, there
should be no problem with not including it with Gnash. I'd only do this
if you were making substantial changes to the AGG sources that weren't
getting accepted by the upstream maintainers that Gnash was dependent
on. All the Gnash docs will have pointers to where to get AGG as a
package and the sources for those occasional distros that don't include
AGG. This is how all the external dependencies are handled currently.

  I'd prefer not to have Gnash totally dependent on AGG for internal
rendering functions. We've had enough headaches with OpenGL being used
in places it shouldn't be, making threading difficult. If AGG has an
OpenGL driver, we shouldn't need to render bitmaps ourselves, it should
be handled by the driver like Cairo does. It may be that the AGG backend
is such an improvement over the OpenGL one performance wise, that it
becomes the primary backend for Gnash. But until it's in CVS where the
rest of us can play with it, I can't really say at this time.


        - rob -




reply via email to

[Prev in Thread] Current Thread [Next in Thread]