Am 28.07.2016 19:11, schrieb Keith Packard:
> walter harms <[email protected]> writes:
>
>> 1. I do not want to start an argument here.
>
> Your comments are welcome and helpful.
>
>> but i seems i need to explain what i wanted to say:
>> "b and c do not change inside the loop"
>>
>> that does *not* mean I have to say: const double or so.
>
> Right, the 'const' comment I made was purely about the attributes
> advertised of the 'pow' function from glibc -- a function marked like
> this:
>
> double mypow(double a, double b) __attribute__ ((const));
>
> does allow the compiler to pull the computation out of the
> loop. However, glibc *doesn't* mark pow like this, so it isn't getting
> optimized as expected.
>
>> In my experience just moving that outside the loop give the
>> compiler enought insight.
>
> Yup, a patch that does that would be welcome.
>
Hello,
I was looking into that famous formula again, and perhaps there is a
issue. when gamma=0.0 you get 1/0 and ups, no clue is that is a real
problem.
My suggestion as drop-in replacement below:
#include <float.h>
static void
init_one_component(CARD16 *comp, unsigned size, unsigned shift, float gamma)
{
int i;
double b,c;
if (gamma == 1.0) {
for (i = 0; i < size; i++)
comp[i] = i << shift;
return;
}
if (gamma == 0.0 )
gamma=FLT_MIN;
b=(double) (size - 1) * (1 << shift);
c= 1.0 / (double) gamma;
for (i = 0; i < size; i++) {
double a=(double) i / (double) (size - 1);
comp[i] = (CARD16) (pow(a,b)*c);
}
}
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
