Re: Drawing optimization question

[Fred Kiefer]

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]

Why would you want do do this yourself? This is what the view drawing 
code tries to handle for you. If you just put your drawing code into
[myView drawRect:] things should be handled efficiently and cleanly for 
you. Only if you need immediate feedback (highlighting?) you may have 
the need for direct drawing.
If you go through the GNUstep GUI code, you will be surprise how rarely 
flushWindow needs to be called explicitly.

> The problem is high CPU consumption occurs for the X server (not
> the app) when this happens repeatedly.  I'm guessing this is because
> the entire window is being flushed, rather than just the changed portion
> (which is usually small).  My questions:
>
> - Is this a correct interpretation of what is happening?  NeXT's
>   docs
>    (http://www.channelu.com/NeXT/NeXTStep/3.3/nd/Concepts/Performance/ 
> D_ImprovingResponseTime.htmld/)
>   say the Window Server maintains a "dirty rect" of what has been
>   touched in the buffer and just flushes this, but is this true in
>   GNUstep?
>
> - Is there any way to explicitly flush just a portion of the window?

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.
Again drawRect: would resolve this for you.

> - Alternatively, could I just cause the drawing to go directly to X,
>   and do away with the flush completely?
>   I thought NSBackingStoreRetained would do this, but the results I
>   get with it are not what I'd expect.

NSBackingStoreNonretained would be the one to draw directly. But I am 
not sure if this makes much of a difference.

I think, you should explain first, why you want to bypass the usual ways 
of drawing in GNUstep. Only if there really is no way to fit it in 
there, should you go ahead with this approach. Even the standard GNUstep 
drawing may still be slow, but at least there we know, we only draw what 
we need to draw. And of course should go ahead and try to optimize this.

Fred