[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: Thu, 10 Mar 2005 10:59:02 -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:.

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

reply via email to

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