On Wed, Dec 20, 2000 at 02:34:19AM -0600, Federico Mena Quintero wrote: > You have to make sure that the code that uses such techniques indeed > has 255*255 as an upper bound. A long time ago the GIMP was full of > inconsistencies where some parts assumed 256*256, others 255*255, yet > buggier ones 256*255. Eeek! We really need to buy some people a "CG for newbies" book, this mistake is why I got mixed up in the Mozilla compositor in the first place - it was producing incorrect results making stuff look awful. > In the border cases (alpha = 0, alpha = 255) this produces exact > results. In the intermediate ones, the maximum difference between > doing a "slow but accurate" division and all this bit twiddling is at > most 1. So it is just what you want. This would probably be OK for display, but it's not acceptable in the Gimp's internals where errors might propagate. > I think the bigger problem is auditing the GIMP to make sure that > there are no inconsistencies in the valid ranges for color values when > compositing stuff together. If there are parts written by people who didn't know this stuff very well then yes, I guess it would need auditing. As I said, this would be a target for 1.2.x x>0 or 1.3. > What code does Mozilla use? If it is different, could we run some > benchmarks for speed and accuracy? #define FAST_DIVIDE_BY_255(v) ((((v) << 8) + (v) + 255) >> 16) Eerily similar to your hack and to the one from Marc. For me (PII 300, AMD Duron 700) and for the other hackers on that Moz bug who checked it _was_ faster than the GCC emitted alternate, but Marc's numbers suggest otherwise. The above hack was tested to work 0 ... 65025, I'm happy to run speed trials or repeat accuracy checks on Sun and Intel hardware in our lab if someone wants to suggest a reasonable "benchmark" code fragment. Nick.
