On Wed, 2010-08-11 at 05:25 +0200, Soeren Sandmann wrote: > Benjamin Otte <[email protected]> writes: > > > On Wed, 2010-08-11 at 04:41 +0200, Soeren Sandmann wrote: > > > The main problem with moving to floating point is that all the test > > > suites will break. We'll need to figure out of to update that, but > > > fundamentally, I don't see a problem moving to floating point > > > unconditionally. > > > > > From a Cairo POV, that is just updating the ref images and looking funny > > at people that use an "old" pixman. We have never been very > > backwards-compatibility sensitive in our test suite. > > Right, backwards-compatibility is mostly irrelevant. The problem is > that floating point doesn't necessarily produce bit-exact results from > machine to machine. (Even if you assume bit-exact output from IEEE > 754, we'll likely still want to use instructions that have more or > less internal precision, or compile with -ffast-math or whatever). > > Basically, the test suites need to understand tolerances. That may not > be too difficult for cairo, but for the pixman test suite, it means we > can't really base it on CRC checks anymore (although those may still > be useful to catch unexpected rendering changes). Instead, we might > want to allow pixman_implementations to be turned on and off > dynamically so that their outputs can be compared to each other.
I had the same testing problem with a floating point imaging library that I am building currently. I ended up using ImageMagick's compare utility with -fuzz set to an appropriately small number. It's fairly slow, but very good about smoothing over platform related issues. And, of course, it was very fast to implement. > Soren > Cheers, Terrence _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
