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

From: Maxim Shemanarev (mcseem_at_[hidden])
Date: 2002-05-13 00:12:30

----- Original Message -----
From: "Martijn W. van der Lee" <martijn_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
Sent: Friday, May 10, 2002 1:55 PM
Subject: Re: RE: A preliminary proposal: AGG project

> Is this exposed in the interface, i.e. can you draw a line from point (10,
> 2) to (10.5, 223.4212)?

Yes. Value 223.4212 will be rounded off to 223.421875 (the nearest
multiple to 1/256), but it does not really matter :-)

> Also this brings up another limitation, namely the maximum dimensions of a
> canvas. If 32-bit ints are used, the max. width would be about 16.7M. No
> problem here, however, if in the future AGG were to support 16-bit color,
> you'd have to shift the ints by 16 bits, limiting the resolution to 32K,
> enough for screen display but not so for modern printers.

No. The subpixel accuracy and the number of aa-levels are two
different things. You can use subpixel accuracy of 1/16 of pixel
still having 256 levels of anti-aliasing.
A canvas of, say, 64K x 64k pixels means great resolution
and that there's no strong necessity of using 8-bit subpixel accuracy,
4 bits ot even less is quite enough. Besides, I'm not sure if
Anti-Aliasing is needed at all, because such resolution will
exceed the abilities of your eyes.

> > I probably will use a template class for it.
>
> This was the one I was going for. Perhaps is a scanline could consist of
> structures for this (not sure if this is what you meant in that last
> sentence).

I meant these very structures, at least a possibility to use more than
8 bits per pixel.

> In theory, does the design of the pipeline allow for other implementations
> of AGG to specialize these primitives?

Yes. It completely depends on how the rasterizer interprets
the vertices. The current rasterizer assumes that it should be a polygon,
another one can consider them as separate wu-pixels of a certain size
and/or shape.
But on the other hand, the pipeline operates only with
2D vertices (x,y) but not with their attributes, such as color,
pixel size/shape and so on. This is actually another open
design issue, how to transmit and transform vertex attributes.

> It's not so much a quality problem as it is a problem of the result being
> visually wrong. Imagine a red pixel at 50% transparency, now add a green
> pixel at 50% transparency. What result will this mixing yield? It _should_
> be a very green shade, not yellow. PhotoShop reports this test as 25% red,
> 75% green, no blue at about 89% transparency (after flattening, during
> drawing PhotoShop uses approximation).

It depends. If you're modeling a real world transparency, such as looking
through a 50% transparent glass to a picture, you're absolutely right.
But, the anti-aliasing also works with transparency, it's another case
of thransparency, and, IMO, the value of a pixel that has 50% coverage
should be namely yellow.

> Try the WildCat cards (I believe from 3DLabs), they're for the
professional
> CAD workstations and will probably include some high-quality stuff.

I would. If they didn't cost so much :-) $3k for a videocard -
phew, I can't afford it.

> As for libraries, have you thought of Intels' high-performance graphics
> library?

I know people involved. Some of them are my former colleagues who
work in far Russia in Nizhny Novgorod city :-) They actually made this
project for Intel (it had work-name "GE", Geometric Engine), actively
cooperating with ID Software. Their project is not what I do. Basically
it's namely Geometric Engine dedicated for high performance geometric
transformations independently of the rendering technology.

McSeem
http://www.antigrain.com