Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-10-19 19:59:21


Ullrich Koethe wrote:
> Joel de Guzman wrote:
>>> I had a look at Fusion, but I'm not sure whether it would be helpful in
>>> this context. TinyVector is based on three design goals: it should support
>>> the std::vector interface (except for resize etc.),
>>
>> Like boost::array?
>>
>
> Similar, but more sophisticated. E.g. it has separate view templates that
> don't own the data, and provides a number of mathematical functions with
> loop unrolling.

There are some code in libs/fusion/example/performance that shows
huge performance improvements with applying fusion algorithms on
boost::array over std algorithms. This is due to the fact that
fusion does the loop unrolling for you, automatically since it
does compile time recursion instead of loops.

>>> Fusion may be more helpful in heterogeneous pixel
>>> types, but they often have very specific requirements that are perhaps
>>> better handled explicitly.
>>
>> Like what, for example?
>>
>
> How about RGBA? How would a Fusion version of alpha blending two pixels
> look like? The formula is
>
> RGB' = alpha2*RGB2 + (1-alpha2)*alpha1*RGB1
> alpha' = alpha2 + (1-alpha2)*alpha1
>
> where pixel 2 is in front of pixel 1. Alternatively, with premultiplied
> alpha we have
>
> RGBA' = RGBA2 + (1-alpha2)*RGBA1
>
> When the individual channels are represented by uint8, we must add
> functionality to stay in the range 0...255.

Ok, that will be the challenge. Fusion can definitely work on
homogeneous as well as heterogeneous structures. And this case
will be easier to optimize because of the use of ints (uint8)
and simpler _flat_ structures unlike Andy's more complex use of
matrices and doubles (c++ can't actually have compile time floats).
I bet Fusion's compile time metaprogramming will work in our favor
this time. I'll get back to you on this but it might take some
time, ok?.

Regards,

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

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