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

From: Martijn W. van der Lee (martijn_at_[hidden])
Date: 2002-05-10 03:55:32

> > 2. How is anti-alias calculated, using FP-math or scaling?
>
> It's completely in integers, usung subpixel accuracy in format 24.8.

So how are you coping with floating point coordinates, assuming AGG supports
these?

> > 3. Where in the pipeline is the anti-alias correction performed, before
or
> > after what stages?
>
> It's not in the pipeline. The pipeline works only with vertices and
> edges, not knowing anything about how it'll be rendered afterwards.
> The responsibility of anti-alias takes the polygon rasterizer class
> (agg::polyfill). It also does not use the traditional oversampling
> technique and performs the rendering in one pass.

Does this mean that resolution in the anti-aliassing is lost in the
correction? After all, some of the possible 256 levels will be "corrected"
away no matter what. If you have an internal representation of considerably
more than 256 levels, this wouldn't be problematic, though.

> > 4. What primitive drawing algorithms are used (bresenham, finite state
> > machines, etc..)
>
> Well, the only low level primitive is polygon. agg::polyfill works
> similar to glyph renderers with calculation the exact coverage
> for each edge pixel. It does not use Bresenham directly.
> Can you explain what do you mean "using finite state machine" when
> rendering?

I'm not that well-versed on the details of line-drawing algorithms, mostly
using Bresenham or my own algorithms but apparently, the fastest way to draw
a line is by using a finite state machine. The Amiga (remember that one :)
apparently uses this technique. Then again, in the world of floating points,
a recursive interpolation would probably be fastest.

> > 5. Is 16bit-per-channel supported or, any other non-8bpc mode.
>
> Yes. Although it's not implemented now, I plan to do that. Actually,
> any mode is considered as a colorspace and all you need is to implement
> a very simple scanline renderer class.

Considering the fact that you're using integers internally, what is the
maximum colordepth supported?

> > 6. How about reading pixel information. Are you using interpolation of
any
> > kind?
>
> Can you explain it?
> If you mean pixel image transformation algorithms, yes, I do use
> interpolation.
> (but you won't find it right now in the library - it's in process).

This really is only of importance when you're using floating point
coordinates in a getpixel() or, indeed, in image transformation (i.e.
rotation or scaling of entire bitmaps). There's a lot of different
interpolation algorithms all with their respective benefits (quality) and
penalties (performance). I'd love for AGG to allow some sort of callback to
let developers implement their own interpolation algorithm.

> > 7. Are fixels/wu-pixels supported and, if so, are they rectangular or
> > circular?
>
> Well, afaik, fixels and wu-pixels are completely diffedrent things. Am I
> wrong?
> Wu pixels are not supported directly, but the rendering algorithm uses a
> very similar idea: http://www.antigrain.com/img/subpixel_accuracy1.gif

They pretty much boil down to the same thing and are used interchangeably
all over the internet. Once again, these are only usefull when you've got a
putpixel() with floating point coordinates.

> > 9. Is there any gamut detection/limiting ability?
>
> Not yet. In general, Color Management topic is not covered. All AGG has
> is a possibility to set a gamma-correction array for anti-aliasing.

Perhaps you could implement a callback, simple one which passes a color out
and returns the corrected color, or for the gamut detection, a boolean
value?

> > 11. How does AGG handle alpha mixing?
>
> I use quite a traditional formula in the existing renderers. But,
> again it's completely up to the scanline rendering classes.

This is a thing a lot of people get wrong. It's quite a mathematical problem
and I only know the formula for a reasonable approximation but this is a
>very< important issue.

> > 12. Can the channel mixer be customized to allow for additive,
> > multiplicative and other mixing modes?
>
> Yes. The concepts of the library allow to customize it. I intend to
> implement a whole bunch of rendering classes with all these possibilities.
>
> > Granted, the above questions may not apply for the average application
> doing
> > graphs or chart but any serious graphics application can't do without
> them.
>
> What do you mean "any serious graphic application"? Does a GIS system need
> to support YUV colorspace for example?
> The variety of graphic applications is great and if it does not use
> something
> mentioned above it does not mean it's not serious :-)

My apologees. A GIS system does not need YUV, nor 16-bit displaying. Then
again, although a GIS system does display graphics, it's main reason for
being is not drawing perfect circles but displaying realistic maps and
convey non-graphical information, which is quite a different thing. I meant
things like desktop publishing software and other applications whose sole
purpose is to render those primitives.

> Basically I develop AGG keeping the SVG standard in mind, but it does not
> mean
> it will have an interface similar to SVG's DOM one. The approach in AGG is
> different. I'm trying to propose a sort of new design concepts for graphic
> libraries accompanied with nice and high quality graphic algorithms.
> Not all of it can be covered because my physical and mental abilities are
> limited, I'm just trying to do what I can do well :-)

And you're work is much appreciated, apart from OpenGL there is no standard
in the graphics world and OpenGL is anything but precise so we could do with
a good graphics framework.

As for complaints about support for specific hardware architectures, you may
have noted I did not mention these since I wholeheartedly agree with drawing
raw data only.

regards,
Martijn van der Lee