[cairo] _cairo_color_compute_shorts fails with FPU set to single precision

[Bill Spitzak]

Why not put the clamping and conversion into the same code? This would 
certainly be faster than clamping the floating point ahead of time. 
Doing the comparison in floating point makes NaN work (in this case it 
will turn NaN into 65535):

if (f <= 0) x = 0;
else if (f < 1) x = (int)(f*65535);
else x = 65535;

Generally I have found that if you have a floating point variable, you 
should never clamp it. If there is any math done at all, you pretty much 
have to clamp the result, so the initial clamp is a total waste of time. 
Also it results in incompatability if you later try to switch to HDR.

As far as I can tell the only effect is that if you set a cairo color to 
2 and then ask for it back, you will get 2 rather than 1. Some people 
would consider this an improvement.

I also really want that 8-bit interface so that the most common use 
avoids all this and we don't have a back-compatability nightmare because 
programmers have used every value in the range that converts to a 
certain 8-bit number and cannot have any change that will make any of 
those values convert to a different one.

Carl Worth wrote:
> On Wed, 30 Aug 2006 16:22:23 +0000 (GMT), Fabien Costantini wrote:
>> De : Behdad Esfahbod <behdad at behdad.org>
>>>> i -= ((i >> 16) & 1)
>>> That doesn't really help, other than slowing it down.
>> well, it just make sure you will substract at max 1,