Boost logo

Boost :

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.


> 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.


> 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.


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

  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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at