[Top][All Lists]

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

Re: Drawing optimization question

From: Adrian Robert
Subject: Re: Drawing optimization question
Date: Wed, 09 Mar 2005 15:34:22 -0500

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

- 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'll try this as well.

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.

Short answer: this is the way the Emacs code is and I don't want to change it since it worked efficiently and well on 25 MHz NeXT all the way through OS X on a G5.

Longer answer: Emacs is weird because it runs two event loops simultaneously (the Lisp/Emacs one being primary) and deals out draw requests piecemeal to the windowing code, therefore it's not easy to use the standard GNUstep [view drawRect:] approach for every case.

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.

I don't see any problem in GNUstep, except maybe the flushWindow could guess the rect better. I'm experiencing a situation where the CPU is limiting text rendering and cursor movement speed in Emacs, but 90% of the CPU is going to X, and only <10% to the GNUstep app. I'm pretty sure the suggestions you made will resolve this.


reply via email to

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