[cairo] _cairo_color_compute_shorts fails with FPU set to single precision

[Behdad Esfahbod]

On Wed, 2006-08-30 at 10:20 -0700, Bill Spitzak wrote:
> 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;

Looks totally rad.

> 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 agree.

> 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,
-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
        -- Dan Bern, "New American Language"