Alexander Malmberg wrote:
GSCurrentThread(), yes. I'll change it to use that function instead.
However, without doing any real benchmarking, I feel that this is
relatively cheap compared to the updating of invalid rects in the view
hierarchy and the (eventual) redraw.
I just noticed that the NSThread.h declares it to be public, yet
NSThread.m has an inline directive. This should probably be fixed.
+ {
+ [self performSelectorOnMainThread: @selector(_setNeedsDisplay_helper:)
+ withObject: [NSNumber numberWithBool: flag]
+ waitUntilDone: NO];
Where is this method declared/defined?
NSThread, a recent cocoa addition.
Ahh, just found it, mad a typo in my find/grep. Note that this method
executes in the defaultThread. Therefore the gui might need to assert
that its also setup in the default thread.
The whole notion of mutiple threads explicitly or implicitly
interafaceing with the gui seems rather dangerous to me, but I guess
that shouldn't concern -gui.
I agree, I'm not certain that we should provide any thread-safety in
-gui at all. Eventually, it'll all have to be drawn in one thread
anyway. What did OPENSTEP do?
It draws only in the main thread. I believe the OPENSTEP for Mach
WindowServer was able to cache the windows contents and redraw it from
there, if any window got partially covered during a long operation of an
App, but OPENSTEP Enterprise just shows white rects until the main tread
is ready to draw again :-( making users believe the app is crashing.
Cheers,
Dave
_______________________________________________
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
