[SciPy-dev] Anti-Grain Geometry

Sun Nov 24 19:04:19 EST 2002

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 at scipy.net [mailto:scipy-dev-admin at scipy.net] On
> Behalf Of eric jones
> Sent: Sunday, November 24, 2002 4:18 PM
> To: scipy-dev at scipy.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 at scipy.net [mailto:scipy-dev-admin at scipy.net]
On
> > Behalf Of M. Evans
> > Sent: Saturday, November 23, 2002 10:17 PM
> > To: scipy-dev at scipy.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 at scipy.net
> > http://www.scipy.net/mailman/listinfo/scipy-dev
> 
> 
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev