Re: [boost] Re: Re: A preliminary proposal: AGG project

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-05-06 23:51:24

On Sunday 05 May 2002 04:02 pm, you wrote:
> 1. Inclusion any non-trivial algorithm into the pipeline (that supports
> only InputIterator for some reason) will degenerate the whole
> pipeline to InputIterator. Since any pipeline will most probably
> contain at least one such an algorithm, the only type of iterators
> available will be Input one. So, in general there's no need to
> implemen other types, such as RandomAccessIterator.

That's fine, and I expected as much.
 
> 2. I told you not all the truth :-)
[snip]
> Any VertexSource is a multi-path, which consists of a number of
> paths, separated with flag pathflag_stop. It's not quite a vector
> of paths, because in case of a storage it uses only one memory
> pool for all the paths. It allows to reduce the memory overhead and
> to avoid reallocations (class path_storage never reallocs memory).
> The reset_iterator method has an integer argument which has a
> sematics of an abstract ID. When we form the path somehow,
> we in parallel create a vector of attributes and then, when rendering,
> use this argument as an ID to associate a particular path with its
> attribute. I'll illustrate this idea with the SVG syntax:
[snip]

This isn't much different from a more container-like interface where begin() 
and end() take the integer argument, e.g.,

struct VertexSource {
  typedef /* implementation-defined */ iterator;

  iterator begin(int pathnum);
  iterator end(int pathnum);
  int numPaths();
};

As for the storage, the iterators can hold pointers to storage in the 
VertexSource, or storage can be inside the iterator. Am I correct in assuming 
that rendering is a parallelizable process? If it is, then the interface I 
gave is perhaps more suitable to parallelization, because if numPaths() 
returns N paths, N threads could be spawned and the i-th thread is given the 
vertex iterator range [begin(i), end(i)) to render.

> I tried to create as simple interface as possible with keeping
> good flexibility. The example looks very simple, however, it's not
> easy to render it. The basic renderer can draw only polygons and does
> not have a possibility to render strokes, so, we have to use more than
> one pipeline to process it.
>
> struct path_attr
> {
>    bool fill;
>    bool stroke;
>    agg::color fill_color;
>    agg::color stroke_color;
>    double stroke_width;
>    agg::affine_matrix transform;
>    unsigned path_id;  // This is that very ID mentioned above
> };
>
[snip]
> The key moment is that we can easily afford to use a generic container to
> store the attributes while using it for vertices can seriously affect the
> performance and/or result in great memory overhead with endless
> reallocations. So, I used a custom container with custom access
> mechanism and custom memory allocation strategy.

This depends on the generic container you are using. Sure, std::vector<void*> 
or std::list<boost::any> will be horrible, but what about 
  boost::tuple<bool, bool, agg::color, agg::color> 
shouldn't impose much overhead.

> Maybe graphics is too specific area for BOOST to be generalized in a
> way all other parts are.

I think the area of graphics (at least, this type of graphics) is 
generalizable, and I think you have the rendering pipeline idea right. 
However, I think there is benefit in reusing existing interfaces (e.g., the 
InputIterator concept) for two reasons:
  - The iterator concepts are used in many STL algorithms. Perhaps some of 
these algorithms can find reuse in the area of graphics? (Code reuse)
  - The iterator concepts are well-understood, so someone unfamiliar with AGG 
can understand its concepts (especially the notion of a pipeline) quickly by 
using preexisting knowledge. (Knowledge reuse)

I can't think of any argument against an iterator-centric interface for 
vertex sources and transformations, but I'm neither familiar with AGG nor 
with graphics. 

> I admit I'm not very experienced in BOOST libraries and this is why I'm
> looking for help from BOOST gurus, because it'll take a lot of time
> for me to completely integrate AGG with BOOST. Besides, I wouldn't
> like to restrict AGG with BOOST only, and so, I'd like the low level of
> AGG to be independent on BOOST.

Boost is just a collection of libraries. AGG can become one of those 
libraries without depending on any other Boost library. 

        Doug