[cairo] _cairo_color_compute_shorts fails with FPU set to single precision

[Carl Worth]

On Thu, 31 Aug 2006 11:41:33 +0000 (GMT), Fabien Costantini wrote:
> Well epsilon seems useful this time because it will bug otherwise if values are between [1.0-1.e-20,1.0[
> i.e: the following example:
>      int v = (int) ((1.0-1.e-20)*65536);
>     printf("val = %d\n",v);
>
> will return 65536 (at least with my intel P4 ).

Right. So for the input values in (0.0, 1.0) we use the approach
proposed before:

	i = f * 65536.0;
	i -= (i >> 16);

and we should be all set. That way we can be free from relying on any
epsilon value. The bug we're trying to fix here is precisely that an
epsilon value chosen and tested on one system is causing failures on
another system, (and the "system difference" here can vary at run time
through FPU mode changes, so even characterizing the system at
configure-time doesn't help).

As for whether the clamping for <= 0.0 and >= 1.0 happens in this
function, (_cairo_color_compute_shorts) or "earlier" is really not
significant in the current implementation since the compute_shorts
functions is only ever called immediately after accepting the input
values from the user.

There is a question of whether a query function should return a
clamped or an unclamped value, but we're also quite fortunate in that
regard: Currently there is no query function for color values. We do
want to add this, of course, but we're free to decide how that should
work without any concern about backwards compatibility.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060831/1aeb198f/attachment.pgp