Re: [pygame] New transformations for future Pygame releases

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

On Sun, Mar 9, 2008 at 11:28 AM, Richard Goedeken
<SirRichard@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>  Yep, you're right; I was looking in the wrong place.  AGG does look quite
>  impressive.  It's big enough that it probably deserves its own pygame module if
>  it were to be integrated.  One possible concern that should be considered is
>  speed.  Since pygame is designed for games, these operations need to be fast
>  enough to be practical for pygame-based games.  Usually there is a trade-off
>  between speed and quality, and it looks like AGG is targeting maximum image quality.
>
I have a fair bit of experience using AGG for real-time 2D games, and
because of it's configureable-templated-pipeine architecture, it's
really trivial to pick between the higher-quality but slower solution
and the much faster solution for whatever piece of an operation you
want to configure. Maxim (the author) definitely put a lot of time
into making pieces that do very high-quality rendering, but he has
also done a lot of performance/optimization work as well, so in
general there is very little left to optimize vs. agg code in terms of
how you write the code. It's more about what operation you choose to
do.