RE: [boost] A preliminary proposal: AGG project

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

> > I can't imagine we would be interested in a graphics library 
> > unless it ran on both Windows and UNIX-like systems, and had
> > good prospects of running on the Mac and other platforms.

False.

> Personally, I think Maxim should focus on the rendering part of the
> effort, because this is the unique part of AGG. It provides some of the
> best quality rendering capabilities, I have seen. This is where AGG has
> the edge.

True.

> In order to get cross-platform rendering fast, he could hook it up with
> SDL. That would allow Unix and Mac users to try it, and help out.

False.

I consider it a fact that any library that can be considered for 
standardization, which after all is the intent of the Boost libraries, 
must not contain any platform specific features apart from thos which
can be customized via policies or similar features. In that respect AGG is 
100% correct on concentrating on being able to render onto an /internal/ 
pixel buffer, whose configuration the user is able to change.

As a platform specific convenience the user must be able to copy the pixel 
buffer to a platform specific device using platform specific utilities. 
This involves being able to configure the representation of the pixel 
buffer and no more. Nothing more.

Any idea of being able to call directly for example some DirectX or OpenGL 
library from a standard *2D graphics library* is doomed for failure due to 
platform optimized changes in the long run. The one an only thing one can 
rely on is that there is some kind of a pixel buffer with some kind of 
access to individual pixels.

As such the only thing AGG or any other possible suggestion for a 
standard *2D graphics library* should only consider features which are 
considered essential for rendering 2D pixel images.

A well thought out example of such a feature set is the SVG graphics 
format, Java2D is a bit more restricted. Standards like GKS are thoroughly 
outdated in todays antialiased an object oriented world and should not be 
considered at all.

Among the most important features of SVG, which must be considered for 
implementation are:

  o A container being able to represent a path consisting of path elements
    of various type. These include quadratic and cubic Bezier segments,
    elliptic arcs, lines and "moveto" segments.

  o Higher level graphics elements, which can be mathematically mapped
    into an equivalent path. This includes circles, ellipses, rectangles,
    rounded rectangles, and as the SVG drafts specify, possibly spirals 
    etc.

  o The user must be able to specify how the colours are to be blended 
    while filling or stroking a graphics object. This includes the set of 
    Porter-Duff rules as well as the more advanced methods found from
    applications such as Photoshop (Brighten, Darken etc). These are all
    mathematically given in either the current SVG standard of existing
    SVG draft documents, there is no ambiguity on how such things should
    be implemented.

  o The user must be able to use a filter on the rendering of any given
    graphics element. This does not imply that a low level graphics 
    library must support the complete SVG rendering model, with temporary 
    pixel buffers to hold filtered elements etc, but what it does imply
    is support for filtering the *given* pixel buffer so that the SVG
    rendering model could be implemented. The available filters are
    formulated exactly in the standard.

  o The user must be able to specify linecap, linejoin etc features
    as the SVG standard specifies. There is both an existing standard
    on how to specify them in the form of SVG as well as a de facto one
    from the long lived PostScript graphics format.

As such, I thoroughly object to any requests for any platform specific 
support, apart from support for example for RGB data ordering instead of 
BGR to support endiannes an similar low level platform specific choices.

Also, given the intellectual investment spent in for example SVG, I would 
object to having a low level graphics library which would *not* implement
the *rendering* features found essential by a group of 2D graphics 
experts.

In summary, in my opinion AGG should support most of the features required 
for implementing a SVG API or a Java2D API, but not much more. Or less.

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