[boost] RE: A preliminary proposal: AGG project

From: Mika Heiskanen (Mika.Heiskanen_at_[hidden])
Date: 2002-05-03 11:33:14

Regarding the suggestion on demonstrating the validity of the AGG
approach by providing examples for various platforms, I'd like to
reiterate my position:

  Any library to be added to the C++ standard library should not
  concern itself by considering how to directly support a given
  API on a given platform. In the particular case of rendering 2D
  vector graphics onto a pixel device, this approach is doomed to
  fail, since the least common denominator of any such platform
  specific API is the representation of the pixel data itself.
  Anything higher level, and we're already talking about rendering
  itself, which the library is supposed to do itself.

Hence, any request to support the viability of a 2D graphics rendering
library on various platforms is moot. The only thing that must be
demonstrated is that for a given pixel data representation policy
the library is able to render high quality vector graphics.

Thus any request for proof of concept by demonstrating linkage with
OpenGL, SDL, GKS or any other graphics library is requesting proof for
some other concept that a 2D graphics rendering engine, which is the
only thing the C++ standard library can feasibly support in the long run.
OpenGL, SDL etc are beyond the scope of Boost.

If there is to be proof of concept, then the only thing I would require
myself is

  1. A singleton registry for registering various image formats such
     as png, jpeg and gif for both import, export and import type
     matching purposes. The last one involves querying whether some
     iostream contains image data of some specific type or not, filename
     suffixes are not to be trusted, magick numbers and image library specific
     queries are the only reasonably reliable way to do it. This may involve
     proxy classes or some similar pattern, but atleast the three methods
     mentioned above should be supported.

  2. A guide for implementing IO for any desired image format. That is,
     the requirements for the class to be added to the registry.

  3. A guide for implementing self-registering image formats. This is most
     likely as simple as placing an instance of an image format in an
     anonymous namespace in an implementation file, however I am not
     sufficiently fluent in things like template metaprogramming to know
     whether other methods are considered more favourable.

The proof of concept would then consist of for example implementing
PNG and JPEG image formats. The quality of the exported images alone
is sufficient to prove the quality of the 2D graphics rendering engine.

> I got some criticism from Jens Maurer (and I really appreciate it)
> about the concept of pipelines, I mean the interface
> reset_iterator/next_vertex, because it does not correspond with STL
> concepts.  I don't like my idea too much either, but I realize that
> following the STL traditions will make my concept much much harder to
> deal with, and this is my major concern.  See
> http://www.antigrain.com/agg_docs/doc_pipelines.html for some details.

Then perhaps the concept itself must be adjusted. If a library is to
be accepted into *the standard C++ library*, which after all is the
intent of any Boost library, then the library should be consistent
with the existing library. Using a different iterator concept is not
acceptable.

> The main differerence between vertex source interface and
> the general relationship container-iterator is that AGG interators
> (I call them converters) don't have to provide the possibility of
> subranging neither reverse-iterating. For example: a cubic Bezier
> curve is defined by 4 points. The common mechanism of drawing it
> is to approximate the curve by a number of line segments.
> I have a class that accepts 4 points and produces N
> intermediate vertices. The thing is that the class is NOT a container.
> It does not accumulate the vertices and calculates them on demand.
> All it stores is just a few variables that are used
> for recurrent calculation of the next vertex. So, it cannot step back
> neither can start from the middle of the curve. Strictly speaking, it's possible
> for this particular case (Bezier), but can be impossible or extremally
> hard in general. So, I finally refused separated iterators as unreasonably
> complicated stuff - maybe I was wrong. I'd really appreciate if
> someone could suggest something practical for this case.

I believe, but cannot verify right now due to a poor terminal
interface, that Java2D provides two kinds of iterators:

  1. An iterator to traverse the elements of the path. These include
     line segments, bezier segments and so on.

  2. An iterator to traverse the elements of the path *in reduced form*.
     Such an iterator converts Bezier curves etc on the fly based on the
     active flatness parameters. Hence the user only sees moveto and
     lineto segments.

In my opinion, the above iterators are a good thing. If I want to
traverse a path, I either want the original path segment, no matter
how complicated that is, or I want it in the simplest terms possible.
This probably implies having a common base class, but again not
knowing template metaprogramming sufficiently well, I am not sure.

My comments are based on a fair amount of 2D graphics programming
experience, including building such omponents myself. However, I have
never been able to get the time to actually finish one, hence my
comments should most likely be taken with a grain of salt. However, I
do think I recognize a good thing when I see one. With respect to C++,
SVG features, including the planned ones are good, even though the IDL
provided by the standard might not be.

To summarize, any discussion regarding a graphics rendering library in
a Boost mailing list should focus on things a standard library should
support, and nothing else. Support for any existing given platform
specific API is of no concern. Only support for platform independent
standard APIs like the PNG and JPEG image formats must be considered,
and even them only in a user configurable way (perhaps a registry).

--> Mika.Heiskanen_at_[hidden]
    Finnish Meteorological Institute