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.


Reply via email to