[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Drawing optimization question

From: Fred Kiefer
Subject: Re: Drawing optimization question
Date: Wed, 09 Mar 2005 21:14:51 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]