[cairo] _cairo_color_compute_shorts fails with FPU set to single precision

[James Cloos]

>>>>> "Carl" == Carl Worth <cworth at cworth.org> writes:

Carl> I'm not quite sure what you're proposing here. As far as API
Carl> goes, it's really hard for a user to pass the maximum intensity
Carl> value if we accept values only in [0.0, 1.0). So we have to be
Carl> able to accept an input value of 1.0, (which is what we've
Carl> always done and we've documented).

Carl> What are you proposing we change exactly?

When converting from integers, don't try to make i_max convert to 1.0,
allow it to be 1.0 - ϵ.

Document that ≥1.0 are the hdr values.  And that HDR in general is
supported when using float formats.

Allow any input values.

Make sure all conversions from float to int are saturating conversions.
(Incidently, I beleive that sse and altivec — at least — have support
for saturating float to int conversions, so this can be accelerated if
it needs to be.)  +inf should convert to i_max, all -ve values —
including -0.0 and -inf — to 0, and NaNs should go to either 0 or
i_max, and that choice documented.

Most of that is there implicitly in the use of floats ⊂ [0.0, 1.0).
I just hope that nothing changes that, and making it all explicit
should prevent any future limitations.

If everything is explicitly hdr-capable, it will (one hopes) be seen
as a good platform for hdr apps, promote the concept of hdr, etc.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0xED7DAEA6