[boost] Re: A preliminary proposal: AGG project

From: Maxim Shemanarev (mcseem_at_[hidden])
Date: 2002-05-02 22:46:04

----- Original Message -----
From: "Asger Alstrup Nielsen" <alstrup_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
Sent: Thursday, May 02, 2002 4:23 AM
Subject: RE: A preliminary proposal: AGG project

> By hooking up with SDL in addition to the Win32 GDI API, he can
> demonstrate that the base is portable to at least two different systems.
> And he can stay on the same platform, so it is realistic for him to do
> so without spending a year to learn Unix. Alternatively, he could use
> the Win32 GDI API as the first platform, and then DirectX as the second
> platform, but that would not open the code to as many people as the SDL
> path.

I don't think it's reasonable for the library to rely on SDL, but I found it
very
useful for platform independent demo examples. I actually
was looking for something like that and it's almost ideal thing to write
examples. I tried to use OpenPTC (http://www.gaffer.org/ptc/) but found
it not too restrictive (only 8, 16 and 32 bit RGB color formats) and it's,
less developed than SDL. So I prefered not to claim
my examples to be portable and just used what I have. In fact I hate that
ugly AFX and Win32 interface (which, BTW, is rooted from MAC), and SDL is
actually what I need. Besides, it can use DirectX (but doesn't have to) ,
so,
my examples can look much more speedy, because up to 50% of time is
spent now in windows BitBlt call.

As for the library itself, I won't rely on any particular technology or on a
number of them.

> I think the same strategy is the best here: Focus on the core, and port
> it to one extra platform as a proof-of-concept. Then, in a group effort,
> the scope can be extended.

You're right, I don't intend to implement the universe, what I'm trying to
propose
is a platform independent rendering technology. Well, I'm getting myself
into
a mess. Graphics is a very slippery thing, because the approach "interface
is
all, implementation is nothing" does not work here. In graphics
interface and algorithms are EQUALLY important. 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.

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.

McSeem
http://www.antigrain.com