Re: NSView patch

[Richard Frith-Macdonald]

On 22 Feb 2009, at 21:31, Matt Rice wrote:

> On Sun, Feb 22, 2009 at 8:29 AM, Matt Rice <address@hidden> wrote:
> > this just makes debugging a bit easier if you guys want it...
> >
> > bug #25658 appears to be a bug in the NSView display stuff,
> > because some random subset of a views subviews which don't need  
> > display
> > are getting drawRect: called multiple times through  
> > _handleAutodisplay
> > even though they needs_display = NO;
> > with overlapping subviews this causes views which are below other
> > views to be drawn above views which are above them.
> > and its kind of a pain to debug when this flag is being set all  
> > over the place.
>
>
> and here is a fix for the bug i was tracking down....

Please can you explain how this fixes the bug (what the actual bug  
is).  The reason I ask is that, though the idea of making  
NSEqualRects() consider slightly different rects to be equal seems  
fairly reasonable, it does not seem to be how it's implemented on  
MacOS-X.
I found this by writing some tests to determine, by trial and error,  
the largest difference between two constants that was still considered  
equal in NSEqualPoints(), NSEqualSizes() and NSEqualRects() on MacOS- 
X, then changed the code on GNUstep to make it easy to set a  
breakpoint and examine the actual float values used.  When I did that  
I found that the point where values began to be considered equal was  
the point where the compiler made the two constants into identical  
floats.  ie. MacOS-X seems to be doing the same as our existing  
implementation and testing for exact float equality.

If making NSEqualRects() fuzzy about its test for equality fixes your  
problem, perhaps the issue is in the way the function is being used  
somewhere?

> note that tests/Testing.h has a an EQ() macro that makes a
> different type of comparison but I didn't exactly understand what it
> was doing...

It's testing to see if two values differ by an amount proportional to  
them rather than by an absolute amount.  This is generally what is  
wanted if you need to test floats for equality and avoid test failures  
due to rounding errors.

I have some more efficient code to do the same thing ...

BOOL
almostEqual(float A, float B)
{
#define threshold       10      // Arbitrary fuzziness of test
  union {int32_t i; float f;} valA, valB;

  valA.f = A;
  valB.f = B;

  /*
   * Make the values lexicographically ordered as twos-complement
   * integers.
   */
  if (valA.i < 0)
    {
      valA.i = 0x80000000 - valA.i;
    }
  if (valB.i < 0)
    {
      valB.i = 0x80000000 - valB.i;
    }
  if (abs(valA.i - valB.i) < threshold)
    {
      return YES;
    }
  return NO;
}