Boost logo

Boost :

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


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

> This means that if you look at the mixed anti-alias in monochrome, the
mixed
> anti-aliassed yellow would be brighter than the two colors it is composed
of
> and, IMHO looks totally unrealistic.

Hmm, interesting. I've just tested it and the result looks at least
appropriate.
Here it the entire text of the scanline rendering function:

    void render_bgr24_solid::render(scanline* sl)
    {
        if(!sl->reset_iterator(rbuf()->get_clip_box())) return;

        unsigned char* start = rbuf()->get_row(sl->get_y());
        register unsigned num_spans = sl->get_num_spans();

        while(num_spans--)
        {
            if(sl->next_span())
            {
                register const unsigned char* covers = sl->get_covers();
                register unsigned count = sl->get_count();
                register unsigned char* pix_ptr = start + sl->get_x() * 3;

                while(count--)
                {
                    register int alpha = (*covers++) * m_a;
                    register int b = pix_ptr[0];
                    register int g = pix_ptr[1];
                    register int r = pix_ptr[2];
                    *pix_ptr++ = (((m_b - b) * alpha) + (b << 16)) >> 16;
                    *pix_ptr++ = (((m_g - g) * alpha) + (g << 16)) >> 16;
                    *pix_ptr++ = (((m_r - r) * alpha) + (r << 16)) >> 16;
                }
            }
        }
    }

As you can see there's nothing interesting in the mixing formula, but
Here're the results:
http://www.antigrain.com/img/color_mix1.gif (non-transparent)
http://www.antigrain.com/img/color_mix2.gif (half-transparent on black)
http://www.antigrain.com/img/color_mix3.gif (half-transparent on white)

At least there're no visible artifacts in anti-aliased edges.
Maybe 50% transparent red on white shouldn't look so pink :-)

> Would it be possible to choose the used method by means of some option or
> policy or similar?

Of course. The scanline rendering classes can have as much functionality
as you need and I plan to implement a plenty of them with different
mixing formulas, gradients, image stencils and so on. The above
is just a working example of the simplest case.

One of the possible variants is to implement a template class with
a callback similar to:

mix_pixels(color dst, color src, unsigned alpha);

But we should also consider the performance here. You can tolerate
one direct call per pixel (especially considering it can be inlined),
but if you need dynamic polymorphism, be aware that it's gonna be
at least one virtual call per *each* pixel. It's very expensive.

So, the conclusion is we can implement many redering classes
with different properties, but I would not refuse the simplest
and fastest solutions as shown above.

> I consider this issue quite serious.

So do I, but it's in process.

McSeem
http://www.antigrain.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk