[cairo] fixed_from_double speedup masking pixman traps problem

[Vladimir Vukicevic]

I recently checked in a test case, "big-trap.c", that was supposed to 
demonstrate pixman scribbling over memory.  However, I tested it before 
picking up the change to cairo_fixed_to_double; with that change, it 
doesn't crash.  The reason is that the behaviour with overflowing 
coordinates changed somewhat (we're getting different bogus values :), 
and I can't munge the coordinates in the test case again to hit it.

The test case is filling a path that goes (8,8) -> (310,8) -> 
(312,32768) -> (10,32768) -> (8,8)  (a trapezoid) in a 100x100 surface 
with a clip region set (0,0,100,100).  I don't get a crash without the 
clip region set.

Before the change, the two trapezoids that were generated were:

Trap[0]: T: 0x80000000 B: 0x80000003
   L: [(0x000a0000, 0x80000000) (0x00080000, 0x00080000)]
   R: [(0x01360000, 0x80000000) (0x01380000, 0x00080000)]
Trap[1]: T: 0x80000003 B: 0x00080000
   L: [(0x000a0000, 0x80000000) (0x00080000, 0x00080000)]
   R: [(0x01360000, 0x80000000) (0x01380000, 0x00080000)]

After the change, the L/R coordinates are identical for both traps, but 
the top and bottom change:

Trap[0]: t: 0x80000000 b: 0xfda80003
   l: [(0x000a0000, 0x80000000) (0x00080000, 0x00080000)]
   r: [(0x01360000, 0x80000000) (0x01380000, 0x00080000)]
Trap[1]: t: 0xfda80003 b: 0x00080000
   l: [(0x000a0000, 0x80000000) (0x00080000, 0x00080000)]
   r: [(0x01360000, 0x80000000) (0x01380000, 0x00080000)]

I'm not sure why the second doesn't crash and the first one does. 
However, since at this point we're supposed to be in device-space 
coordinates, does it make sense to reject any traps that have negative 
coordinates?  That seems like the simplest fix, though I'm not sure if 
it's correct.  I haven't been able to come up with a test case that 
crashes with the current fixed_from_double code, but I don't think it 
can really be considered "fixed" :)

Any ideas?

     - Vlad