Here is a quick example that demonstrates anti-grain using weave:

I don't quite grok the interface yet, but at least this works (on
windows).

See ya,
Eric

----------------------------------------------------------------
# tst.py
# This will produce a grey filled triangle;
#
# C:\third\agg> python -i tst.py
# > >> import gui_thread
# <wxPython imported> 
# > >> from scipy import plt
# > >> plt.image(res[:,:,0])

import os
from glob import glob
import weave

agg_path = "C:/third/agg"

src_files = glob(os.path.join(agg_path,'src','*.cpp'))
src_files += glob(os.path.join(agg_path,'src','win32','*.cpp'))

include_dirs = [os.path.join(agg_path,'include')]

headers = [ '"agg_basics.h"',
            '"agg_render_buffer.h"',
            '"agg_render_bgr24_solid.h"',
            '"agg_polyfill.h"',
            '"agg_affine_matrix.h"',
            '"agg_converters.h"',
            '"agg_pipe_converters.h"',
            '"win32/agg_win32_bmp.h"' ]

import weave

code = """
       // Note: Need to make way for pixel_map not to own its memory.
       
       
       // Here we create the rendering buffer using class agg::pixel_map
       // which is not a part of AGG and privided only for your
convinience
       // if you program under Windows platform.
 
       // !! Make pointer so that memory isn't destroyed (fix leak
later).
       agg::pixel_map* pmap = new agg::pixel_map();
       pmap-> create(100, 100, agg::org_color24);
    
    
       //Then - create render_buffer and render_bgr24. The only purpose
of the
       //following four lines is to clear the buffer.
       agg::render_buffer buf;
       buf.attach(pmap-> get_buf(), pmap->get_width(),
pmap-> get_height(), pmap->get_row_bytes());
       agg::render_bgr24 rr(&buf);
       rr.clear(agg::rgba8(255, 255, 255));       

       agg::color color = agg::bgr8_packed(0, 20);
        
       // build a path
       agg::render_bgr24_solid r(&buf);
       agg::polyfill     g_polyfill;
       agg::path_storage g_path;        
       g_path.move_to(20,20);
       g_path.line_to(80,80);
       g_path.line_to(40,80);
       
        agg::pipe_path_storage p2(&g_path);    // Wrapper for
path_storage

        agg::pipe_conv_curve curve(&p2);       // Wrapper for conv_curve

        agg::pipe_conv_polygon poly(&curve);   // Convert polygon to its
polyfill,
                                               // used in trans2

        // Below our pipeline divides into two different streams.
        // One (trans1) transforms our polygon directly, accepting
        // curve as a data sourcre, the other (trans2) uses polygon's
        // outline to render a thin border.
        agg::affine_matrix mtx;
        agg::pipe_conv_transform trans1(&curve, &mtx);
        agg::pipe_conv_transform trans2(&poly, &mtx);
        //-------------------------------------

        // Setting the thickness of the outline. It can be done anytime 
        // before rendering.
        poly.set_thickness(2.0);


        // Render the polygon itself
        r.set_attribute(agg::rgba8(100, 200, 200, 255));
        agg::make_polygon(&g_polyfill, &trans1, 0);
        agg::render_polygon(&r, &g_polyfill);

        // Render black outline
        r.set_attribute(agg::rgba8(0, 0, 0, 200));
        agg::make_polygon(&g_polyfill, &trans2, 0);
        agg::render_polygon(&r, &g_polyfill);


 
//--------------------------------------------------------------------
       // Get buffer from anti-grain lib and put it in a Numeric array.
 
//--------------------------------------------------------------------
       
       // vars for building array
       char real_type = 'b';  // UInt8 // & ~SAVESPACEBIT;
       int nd = 3;
       int d[3] = {100,100,3};    
       int sd,i;
       PyArray_Descr *descr;
       PyObject *op;
       unsigned char* data;        
       
        // create descriptor     
        if ((descr = PyArray_DescrFromType((int)real_type)) == NULL) 
            return NULL;
        
        // calculate size of array
        sd = descr-> elsize;
        for(i=nd-1;i> =0;i--) 
        {
        	if (d[i] < 0) 
        	    throw_error(PyExc_ValueError, "negative dimensions
are not allowed");
        	/* 
        	   This may waste some space, but it seems to be
        	   (unsuprisingly) unhealthy to allow strides that are
        	   longer than sd.
        	*/
    	    sd *= d[i] ? d[i] : 1;
        }
    
        /* Make sure we're alligned on ints. */
        sd += sizeof(int) - sd%sizeof(int); 
               
        op = PyArray_FromDimsAndDataAndDescr(nd, d, descr,
(char*)pmap-> get_buf());
        
        // we own data
        ((PyArrayObject *)op)-> flags |= OWN_DATA;
   
        return_val = op;
        """

res = weave.inline(code,sources = src_files,headers =
headers,include_dirs = include_dirs,
                   libraries=['gdi32'],
                   force=1)            

print 'shape', res.shape                   
print 'pixel one:', res[0,0,:]

#C:\third\agg> python -i tst.py
#> >> import gui_thread
#<wxPython imported> 
#> >> from scipy import plt
#> >> plt.image(res[:,:,0])


----------------------------------------------
eric jones                    515 Congress Ave
www.enthought.com             Suite 1614
512 536-1057                  Austin, Tx 78701 


>  -----Original Message-----
>  From: scipy-dev-admin@[...].net [mailto:scipy-dev-admin@[...].net] On
>  Behalf Of eric jones
>  Sent: Sunday, November 24, 2002 4:18 PM
>  To: scipy-dev@[...].net
>  Subject: RE: [SciPy-dev] Anti-Grain Geometry
>  
>  Hey Mark,
>  
>  Thanks for the link.  This looks *very* interesting for Kiva.  It is
>  path and affine transform based.  It also supports alpha transparency,
>  anti-aliasing, and non-zero and odd-even polygon fills.  Best of all,
it
>  is small at 10K lines of code.  Looking at its "path_storage" class,
it
>  has the following methods:
>  
>  move_to
>  line_to
>  curve3
>  curve4
>  
>  Besides arc and arc_to, this covers all that Kiva needs.  Anti-grain
>  doesn't allow paths to have matrix transforms stored in them (which
>  would provide a direct mapping to kiva), but this can probably be
>  handled (or added) without much fuss.
>  
>  Adding anti-grain as a backend would provide a render engine that was
>  completely independent of a GUI system.  We have wanted this, but
>  haven't wanted to do the work.:-)  anti-grain, along with the freetype
>  engine, would remove any reliance on the underlying platform for
>  drawing.  People wanting GIF would really like this.  It would also
make
>  a non-OpenGL TkInter easy -- just blit in the buffer after anti-grain
>  has rendered it.
>  
>  Anti-grain does use C++ templates, but compiles on MSVC 6.0 which
means
>  gcc probably doesn't have problems with it.  It looks like anti-grain
is
>  mainly developed on windows.  Has anyone tried it on Unix with gcc?
>  
>  I played with the C++ examples on windows, and they seemed very
snappy.
>  I'm going to play around with it a little tonight to see if any
>  fundamental problems show up.
>  
>  Thanks again,
>  Eric
>  
>  ----------------------------------------------
>  eric jones                    515 Congress Ave
>  www.enthought.com             Suite 1614
>  512 536-1057                  Austin, Tx 78701
>  
>  
>  > -----Original Message-----
>  > From: scipy-dev-admin@[...].net [mailto:scipy-dev-admin@[...].net]
On
>  > Behalf Of M. Evans
>  > Sent: Saturday, November 23, 2002 10:17 PM
>  > To: scipy-dev@[...].net
>  > Subject: [SciPy-dev] Anti-Grain Geometry
>  >
>  >
>  > http://www.antigrain.com/agg_docs/doc_overview.html
>  >
>  > Interesting library with a liberal license.
>  >
>  > "Anti-Grain Geometry (AGG) is a platform independent C++ graphic
>  > rendering library that is designed to be small and efficient."
>  >
>  > Mark
>  >
>  > _______________________________________________
>  > Scipy-dev mailing list
>  > Scipy-dev@[...].net
>  > http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>  
>  
>  _______________________________________________
>  Scipy-dev mailing list
>  Scipy-dev@[...].net
>  http://www.scipy.net/mailman/listinfo/scipy-dev