[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSView patch
From: |
Richard Frith-Macdonald |
Subject: |
Re: NSView patch |
Date: |
Mon, 23 Feb 2009 06:59:08 +0000 |
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;
}
- NSView patch, Matt Rice, 2009/02/22
- Re: NSView patch, Matt Rice, 2009/02/22
- Re: NSView patch,
Richard Frith-Macdonald <=
- Re: NSView patch, Matt Rice, 2009/02/23
- Fwd: NSView patch, Richard Frith-Macdonald, 2009/02/23
- Re: NSView patch, Nicola Pero, 2009/02/23
- Re: NSView patch, Matt Rice, 2009/02/23
- Re: NSView patch, Nicola Pero, 2009/02/23
- Re: NSView patch, Matt Rice, 2009/02/23
- Re: Fwd: NSView patch, Fred Kiefer, 2009/02/23
- Re: Fwd: NSView patch, Matt Rice, 2009/02/23
- Re: Fwd: NSView patch, Fred Kiefer, 2009/02/23
- Re: Fwd: NSView patch, Matt Rice, 2009/02/24