[SciPy-user] FW: anti-grain

eric jones eric at enthought.com
Wed Nov 27 11:50:46 EST 2002


I pinged Maxim Shemarnarev (McSeem) about anti-grain, and he responded
with this information.  It looks like he is working to make it platform
independent, so Prabhu's worries about *nix compatibility should be
allayed.  We'll definitely make sure any solution chosen will work
everywhere (well a hopefully large subset of everywhere...)

I look forward to technical discussions with McSeem about rendering and
the implementation details of Kiva.  It looks like he is very
knowledgeable and happy to discuss such things.  

Regards,
eric

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


> -----Original Message-----
> From: Maxim Shemanarev [mailto:mcseem at antigrain.com]
> Sent: Tuesday, November 26, 2002 10:17 PM
> To: eric jones
> Subject: Re: anti-grain
> 
> Thank you Eric!
> 
> I'll be happy if AGG can be included in such a big project, because it
> really will be a very good promotion. The project is actually very
young,
> I
> started AGG2 in February this year. I work on it alone, 2 or 3 hours a
> day,
> after my official job hours. I redesigned the current version of AGG
two
> times and I'm constantly working on new algorithms.
> Maybe it'll be interesting if I tell you a brief story.
> 
> AGG was started in 1998 and at that time it was a simple task to write
a
> plug-in for Macromedia Director that would rotate an image with high
> quality
> filtering. I solved this task, and there was only a very simple linear
> filtering method. You could apply arbitrary affine transformations to
the
> images, and you could transform a part of the image of any shape. The
only
> problem was to anti-alias the edges of the image, i.e. the transformed
> image
> itself was perfectly anti-aliased, but it still had very bad
stair-looking
> edges. I developed an algorithm for drawing anti-alised line segments.
> That
> algorithm had perfect line joins (which was the most difficult part of
the
> job). You can see my ancient demos here:
http://antigrain.hypermart.net/
> (sorry about that pop-up windows).
> After that I had to abandon the project because of my personal
reasons.
> After almost 3 years I started again from scratch. There were just
some
> experiments, called AGG-1 (http://sourceforge.net/projects/vector-agg/
> download agg-1.2.2-beta). It was started in October 2001 and released
in
> December, 2001. There were just experiments basically with drawing
> anti-aliased lines. The lines had incorrect joins but most of all,
that
> algorithm couldn't draw correctly very small primitives - they had
nasty
> looking defects.
> Then I found FreeType and its nice rasterizer. AGG2 uses the same
idea.
> David Turner generously gave me permission to use it in my library
(the
> code
> was completely redesigned and improved). It's free of those problems
of
> drawing very small primitives: http://www.antigrain.com/mol_view.zip
(one
> of
> the latest demo examples) - just drag with the left button pressed to
> rotate
> and scale the molecule. Also, press PgUp/PgDown to switch between
> different
> molecules. So, David's algorithm is perfect! It operates only with
> polygons,
> not lines. If you need to draw a line segment, you have to calculate
its 4
> outline vertices (so called path-based approach).
> 
> Then I had to change my primary job and study a lot of organic
chemistry
> stuff. And only in February this year I started again from scratch, on
the
> basis of David's algorithm. All this time I've been mostly working on
the
> design of the library. I did't (and don't) want to use that approach
when
> you have a class like "Graphics" with hundreds of functions. I wanted
to
> create something more flexible. So, AGG now (it's actually called
AGG2) is
> a
> number of independent class templates that you can combine somehow in
> order
> to create a custom graphical pipeline. It even doesn't restrict you
with
> the
> colorspace (well, for now only RGB is implemented). But the
flexibility
> usually means  difficulties in use, that's the rule. AGG now is not an
> "end-user" library, it looks more likely a "tool for creating other
> tools".
> Here is a very simple example:
http://www.antigrain.com/img/conv_order.gif
> Usually you can't control the order of the conversion steps,
especially if
> you have a library like GDI+. With AGG you can do that, but the price
is
> you
> usually have to write a number of very complex nested template
> declarations.
> Still, the pipeline can be organized as a number of polymorphic
classes,
> but
> there will be one virtuall call per vertex on each step, while in case
of
> templates everything can be easily inlined without any explicit calls!
> Then. Arbitrary affine transformations? Phew - that's the easiest
pipeline
> converter, at least the converters that calculate the outline, or
> Bezier-curve converters are much more complicated.
> 
> In August 2002 I finally came back to my favorite topic, image
> transformations. The demo is here:
> http://www.antigrain.com/image_filters.zip
> I combined the path-based approach with images, in other words you can
> transform an arbitrary part of the image and the quality of the edges
of
> your image polygon will be as good as if you rendered a regular solid
> polygon.
> 
> I spent some time to design classes for creating examples in Windows
and
> Linux (just in order to prove the concept of platform independency).
So, I
> had to study Win32 API and X11. That was tough, because I hate APIs, I
> like
> algorithms :-). But now I'm proud that I can provide examples for
Windows,
> for any Unix with basic X11, for MacOS, and for OS X (Carbon API). The
> latest is not ready yet, but coming soon (A guy from Prague wrote the
> platform specific .cpp file for Mac).
> 
> Recently the problem of drawing single lines has arisen again. The
thing
> is
> my old AGG-1 algorithm draws lines 3-5 times faster than the
path-based
> David Turner's algorithm. That's worth the efforts to work on it,
> especially
> considering potential applications of AGG in GIS. I have finally
solved
> the
> problem of line joins (phew!) and I'm working on a good
implemantation.
> Besides, Hansruedi (he's that very guy from Prague) gave me a very
good
> idea
> of drawing lines decorated with arbitrary image patterns:
> http://www.antigrain.com/line_patterns.gif
> AFAIU it's very actual for Geographic Information Systems (GIS) and
can be
> used in any engineering and scientific applications.
> 
> The conclusion is I'll be glad to have a cooperation with your group.
AGG
> is
> designed as a multi-purpose and multi-platform library. My minimal
> objectives are to earn some good reputation. There's still no single
line
> of
> docs and I'm terribly sorry about that, but I'll be glad to help you
with
> some comments and examples because your questions also will help me to
> write
> some docs. And I hope you'll give me some new ideas to work on. That's
the
> deal :-).
> 
> The latest snapshot is here: http://www.antigrain.com/agg2.zip
> Also, there's a public CVS repository:
> http://sourceforge.net/cvs/?group_id=42020
> 
> Please feel free to ask me any qustions and to forward this message to
> your
> group.
> 
> McSeem
> 
> 
> 
> 
> ----- Original Message -----
> From: "eric jones" <eric at enthought.com>
> To: <mcseem at antigrain.com>
> Sent: Tuesday, November 26, 2002 7:08 PM
> Subject: anti-grain
> 
> 
> > Hey Maxim,
> >
> > I just had a chance to play with anti-grain, and it looks like it
might
> > be a really good fit for our chaco scientific plotting project for
> > Python.  It is part of the SciPy (www.scipy.org) tool suite (or will
> > be).  Chaco implements a DisplayPDF backend for a lot of different
APIs
> > (Tk, wxPython, PDF, OpenGL, etc.)  A single anti-grain backend would
> > supplant multiple of these easing the project development and
providing
> > the desired capabilities across all GUIs.
> >
> > I'm running home now, so I can't write more.  I just wanted to let
you
> > know that a reasonably large community is potentially interested in
> > making your tool one of its main underpinnings.
> >
> > I hope to have more productive discussions in the future.
> >
> > See ya,
> > eric
> >
> > ----------------------------------------------
> > eric jones                    515 Congress Ave
> > www.enthought.com             Suite 1614
> > 512 536-1057                  Austin, Tx 78701
> >
> >
> >
> >
> >
> 
> 






More information about the SciPy-User mailing list