Re: Recent drawing optimizations

[David Ayers]

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