[boost] Re: A preliminary proposal: AGG project

From: Maxim Shemanarev (mcseem_at_[hidden])
Date: 2002-05-14 07:09:26

From: "Mika Heiskanen" <Mika.Heiskanen_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
Sent: Monday, May 13, 2002 11:27 AM
Subject: Re: A preliminary proposal: AGG project

> The list of methods built-in into AGG should include the regular
> Porter-Duff rules as well as those proposed for the SVG 1.2 standard
> (which are modeled after the respective options in Adobe products).

Agree. But in many cases you need just simplest and fastest scanline
renderer classes. It's possible to provide renderers with templetized
callback functions and "all stuff", but it does not mean there shouldn't be
simplest ones.

> The complete list of blending modes provided by the library should thus
> include over, in, out, atop, xor and general arithmetic to cover all the
> Porter-Duff rules, plus multiply, screen, darken and lighten as in
> feBlend, and finally overlay, soft light, hard light, color dodge,
> color burn, difference and exclusion as in PDF 1.4 as suggested for SVG
> 1.2.

I read it, maybe not carefully enough, butr at least I'm aware about it.

> Personally, I would like to extend the list more, for example I would like
> to be able to change hue, light etc separately without affecting other
> components. For example, I would like to be able to change a region of the
> image into greyscale. However, such great extensibility does require
> either a functor or a template parameter argument. The latter may be
faster,
> but given the very large number of possible blending modes for example a
> graphics scripting environment may have to support, the functor approach
> might be more space conserving. For speed, perhaps trivial copy and the
> default blending mode (over?) should be specialized though. Depends on AGG
> internals, which I'm still not too aware of.

You don't have to be, since I still did not provide any considerable
piece of docs :-)

> In summary, AGG should not decide what blending mode to use, but take it
> as a parameter. Depending on the interface one may have to provide a
> default though. In that case the 'over' Porter-Duff rule might be the best
one.

BTW, there's an idea. Take any well developed vector graphic editor,
and try to draw a rectangle with gradient. There're a lot of types of
gradients of different shape, functions and so on, but usually no
possibility to apply two or more gradients simultaneosly.
I'd like AGG to be able to do so, namely to have a possibility
to apply many different functions to calculate pixel values.
And the idea is to use a pipeline similar to the conversion one.
Of course it'll be much slower than the simplest renderers, but it'll
be great to have a possibility to *customize* pixel calculation
algorithms. At least I haven't seen it before.
Again, instead of having a great (but still restricted) number of
graphical settings we should think about how to design it extensible and
configurable.

McSeem
http://www.antigrain.com