Re: Drawing optimization question

[Fred Kiefer]

Adrian Robert wrote:
> > On Mar 9, 2005, at 3:14 PM, Fred Kiefer wrote:
> >
> > > Adrian Robert wrote:
> > >
> > > > I'm drawing directly to a view, either using [NSString 
> > > > -drawAtPoint..]  or,
> > > > say, with NSRectFill() and friends.
> > > > I do something like:
> > > >     [view lockFocus]
> > > >       (draw comands ...)
> > > >     [view unlockFocus]
> > > >     [[view window] flushWindow]
> > >
> > > ...
> > > Even [NSWindow flushWindow] will only flush the union of the 
> > > rectangles it thinks some drawing was going on, but it guesses them 
> > > based on lockFocusInRect:, if you locked the whole window, the whole 
> > > window will be flushed.
> >
> >
> > Thanks, I'll try lockFocusInRect:.
>
>
> This worked like a charm..  now X and my app are splitting the CPU 
> equally ;) and performance is vastly improved.
>
> However, this raises the question, where did -lockFocusInRect: come 
> from?  Google shows a paltry 9 pages or so (these emails, when archives, 
> will significantly increase this), all of which I read and none of which 
> give any indication as to its origin.  It's not in NeXT or OpenStep, nor 
> is it in OS X.  Also, what about the related method 
> -unlockFocusNeedsFlush:?  Are both of these just supposed to be for 
> internal GUI use?

Yes, you are right. Living in the GNUstep world only, it took that 
method for granted. According to the changelog Adam added it back in 1999.

> In any case, it seems like a good system and well implemented.  BUT.. if 
> we wanted to implement what *Step/Cocoa does in determining the flush 
> rectangle directly from the portion of the buffer that was modified by 
> drawing, could this be done in GUI, or would it have to be done 
> separately in each back-end?  (Essentially every operation that modified 
> the buffer would have to be wrapped by determine-rect-and-take-union.)

From what I can tell we only used the rectangle that gets passed on to 
lockFocusInRect: for clipping (where we could as well use the view 
bounds) and for exactly that optimisation trick you benefit from. That 
is the line:

[window_t->_rectsBeingDrawn addObject: [NSValue valueWithRect: wrect]];

This rectangle is later (on flush) merged with the rectangel needing 
flushing (window_t->_rectNeedingFlush). To become more similar to what 
Cocoa does, we could try, as you suggest, to keep track of which areas 
of a window we actually put ink on. But this looks a lot more 
complicated to me. One aspect that makes it difficult in GNUstep is that 
we have the separation between the window server and the graphics 
context in the backend. Drawing is done by the later, flushing by the 
former.
We could try to compute the affected rect on the gstate, between the 
DPSgsave and the DPSgrestore call. It would be sufficent to do it once 
in GSGState, still this is a lot of work and a big change.

I really would like a compatbible solution, but currently I am not 
seeing it coming soon.

Fred