Re: Drawing optimization question

[Adrian Robert]

> 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?

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.)