Re: [pygame] New transformations for future Pygame releases

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

On Sun, Mar 9, 2008 at 1:26 PM, Casey Duncan <casey@xxxxxxxxxxx> wrote:
>  Certainly, I mostly pointed them out in case they would be useful to
>  the original poster or useful as jumping off points for a tighter
>  integration with pygame. I think such features tightly integrated with
>  pygame surfaces would be phenomenal. OTOH, it might make more sense to
>  just do such operations on the GPU (which afaict agg does not
>  leverage), granted that may be less portable.
>
well If there was a bunch of rendering api's that pygame provided that
rendered to software surfaces, you could make a hardware supported
implementation of them for hardware surfaces I suppose - but the fact
of the matter is if you would want such api's to work with software
surfaces at all you would need some software implementation, and that
is where agg provides value.


>  So rather than integrate with agg, per se, just reimplement the
>  desired algorithms in pygame? Obviously not having another dependancy
>  is highly desirable, guess it just depends on suitable volunteer
>  motivation.
>
I think I must not be making things very clear - there is no such
thing as an agg binary to link to. It does not exist in library form.
It's basically source code for a butt load of sweet rendering
algorithms. If it was used to implement some pygame drawing stuff, it
would not be an additional dependency, in that relevant sources would
be added to pygame svn, and nobody would have to reimplement desired
algorithms where Maxim already implemented them.