[cairo] _cairo_color_compute_shorts fails with FPU
set to single precision
Behdad Esfahbod
behdad at behdad.org
Wed Aug 30 10:46:06 PDT 2006
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"
More information about the cairo
mailing list