[cairo] rewriting libpixman

[James Cloos]

>>>>> "Jeff" == Jeff Muizelaar <jeff at infidigm.net> writes:

Jeff> I still don't follow this logic, specifically the last sentence.

Then I didn't explain it well enough....

I was actually investigating conversions between floats in [0.0,1.0]
to and from ints in [0,2ⁿ), for any n ∈ ℤ⁺.

In that case, if you mupliply the float by 2ⁿ (saturating at 2ⁿ-1 if
the float was ≥ 1.0) you get sane results.

Also, if you divide the ints by 2ⁿ-1.0 you get results which are
evenly spaced between 0.0 and 1.0 and you generate a repeating
fraction which fills the width of the float.

X11's DIX already does bit replication when expanding to larger sample
sizes.  Eg, specifying a colour of (0xff,0x01,0x7f) will expand to 48-
bit as (0xffff,0x0101,0x7f7f) rather than (0xff00,0x0100,0x7f00).
That change was made to keep colours from washing out towards neutral
gray.

Dividing any single digit value in any base n, (at least for n ∈ ℤ⁺)
by n-1 yields, in base n, an infintite repeating fraction where each
base-n digit is the same as the orginal base-n value.

So, dividing the eight bit value xx by ff results in, in base 256,
the value 00 . xx xx xx xx xx xx xx xx xx xx ... for any xx in [00,ff].

And the same holds for 5 bit values (base 32), 6 bit (base 64), etc.

My hypothesis was that this works just as well when converting between
different sized ints, rather that only to and from floats.

The implementation, though, should still use shifts ORs and ANDs when
converting between ints for performance and clarity.

(I hope everyone reading has good utf-8 support....)

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6