[boost] Re: Vector graphics: Anti-Grain Geometry, second round

From: Maxim Shemanarev (mcseem_at_[hidden])
Date: 2002-04-23 20:52:50

Thanks Mattias!

> Skimming through the docs and header files, I get the feeling that the
> design could be made much more powerful and flexible through the use of
> templates and generic concepts. For instance, one concept common in
> computer graphics is a DDA, digital differential analyzer, plotting out
the
> path of some line or curve. If one could provide this as a function object
> of some kind, a library user could make use of the antialiasing engine for
> any geometrical shapes or functions she likes. It would be great for
> mathematical graphing software, to name one obvious example.

About the flexibility you're partially right, partially not. I will describe
the concept of the conversion pipelines soon, now just some comments.
There's a rendering class agg::polyfill that accepts only straight line
segments in subpixel integer coordinates. It behaves like a DDA,
and it's the lowest level of AGG. Also there's a template function
make_polygon which is very simple, in fact the only thing it does
it converts the coordinates from doubles to subpixel integers.
But it accepts a pointer to any object called "vertex source" that
supports a very simple interface:
void reset_iterator(unsigned id);
pathflag_e next_vertex(double* x, double* y);
Apparently, you can write any class you want, for example,
a sinewave generator which will calculate vertices on demand and
not store them anywhere. Class path_storage is just a special
case of a generic vertex source which has a capability to accumulate
vertices. Moreover, there're a number of classes-converters which
accept any generic vertex source and act as another vertex source.
The examples are: affine transformations, calculating polygonal
outline, smoothing polygons with bezier curves and so on.
So, you can assemble any custom pipeline with any transformations
you want. This is the main difference from classical graphic interfaces,
which assume a fixed number of hardcoded converters, like rortating,
scaling, clipping, whatevering.

Anyway, I thankfully accept your criticism. The weak place
of my concept is that the interface does not correspond with STL
traditions, it does not use separate iterators, for example. I almost
do not use overloaded operators and so on.
I just tried to simplify things as much as possible, keeping
in mind efficiency and minimal overhead.

> So, whereas you apparently have a good code base and some beautiful
> results, I believe the library would benefit greatly from an attempt to
> break down the library into orthogonal concepts and refactor the design.
>
> Against odds I am hoping to find the time to look more closely at the
> library, and if I do I'll be happy to contribute some ideas on how the
> library could be "boostified."

Any criticism and suggestions are appreciated!

McSeem
http://www.antigrain.com