Re: Serious crash from setNeedsDisplayInRect:
Re: Serious crash from setNeedsDisplayInRect:
- Subject: Re: Serious crash from setNeedsDisplayInRect:
- From: Benjohn <email@hidden>
- Date: Wed, 9 Feb 2005 13:40:29 +0000
On 9 Feb 2005, at 13:14, j o a r wrote:
I understand that this is test code, so it might be weird for that
reason
It's weird because it's replicating the salient features of an
application. The application is weird because it's working around
another bug in the framework (discussed in a moment).
- but I have to ask:
* What is the point of spawning a secondary thread, when the only
thing it does is to schedule something back to the main thread? You
could just as well use a timer on the main thread.
In the real application, the secondary worker thread (actually
maintained by a completely separate object) is doing considerable
computation to make gradual updates to a model of the image. Once a
piece of update is finished, it tells the view that it will need to
repaint the bit it's just finished working on (until the piece is
ready, a temporary place holder will have been displayed by the view).
As I mention in the original email, it would be nicer to simply have
the worker thread call "setNeedsDisplayInRect:" directly. However:
* [1] Explicitly says that this is a bad idea.
* There seems to be a bug in the framework (for which I'll try to
write a repro case tonight, if I don't go to the pub) that means that
calls to "setNeedsDisplayInRect:" are sometimes ignored, so our place
holder doesn't get overwritten. My suspicion is that this is because
Cocoa updates the list of rects to repaint after it's finished
rendering, rather than before, so an update arriving while drawing
happens will be ignored.
[1]
http://developer.apple.com/documentation/Cocoa/Conceptual/
Multithreading/articles/CocoaSafety.html
Try setting a breakpoint in dealloc if you wonder why it's called.
:) Yes, I tried that, here's a dump of who's deallocating my view:
#0 0x002ee50c in -[FLThreadedRepaintView dealloc] at
FLThreadedRepaintView.mm:30
#1 0x92dc73c4 in -[NSView release]
#2 0x90a1a810 in __NSFireMainThreadPerform
#3 0x901e4614 in __CFRunLoopPerformPerform
#4 0x90193ca8 in __CFRunLoopDoSources0
#5 0x90191560 in __CFRunLoopRun
#6 0x90195e8c in CFRunLoopRunSpecific
#7 0x927d5f60 in GetWindowList
#8 0x927dc6c8 in GetMainEventQueue
#9 0x927fe6a0 in BlockUntilNextEventMatchingListInMode
#10 0x92dd2e44 in _DPSNextEvent
#11 0x92de98c8 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
#12 0x92dfdc30 in -[NSApplication run]
#13 0x92eba2b8 in NSApplicationMain
#14 0x000e0f74 in main at main.m:13
Cheers,
Benjohn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden