Re: Ways Apple COULD optimize -setNeedsDisplay
Re: Ways Apple COULD optimize -setNeedsDisplay
- Subject: Re: Ways Apple COULD optimize -setNeedsDisplay
- From: Ian Clark <email@hidden>
- Date: Tue, 18 Dec 2001 15:41:43 +0000
On Tuesday, December 18, 2001, at 03:10 pm, Marcel Weiher wrote:
On Dienstag, Dezember 18, 2001, at 03:27 Uhr, Norbert Heger wrote:
Remember, there have been huge AppKit API changes from NEXTSTEP to
OPENSTEP:
NEXTSTEP: View - (id)drawSelf:(NXRect *)rects :(int)rectCount;
OPENSTEP: NSView - (void)drawRect:(NSRect)aRect;
Yes, that was also what I was thinking of. The original API had the
union-rect as rects[0], IIRC. Of course, I think almost everyone used the
union-rect to refresh their own views.
However, the fact that a single view can only update one rectangle at a
time doesn't imply the update process has to create one big
union-rectangle (even though I certainly thought it did at first). It
should be capable of keeping the rectangle-list in order to decide which
views to update, and then create a union-rectangle for each view that it
finds it must update.
Deja vu
In 1997 I had a conversation with a well known Apple engineer on this
subject, who passed my comments on to the then "view guy" who sent me this.
..
...
My idea right now is to internally keep a
list of rectangles instead of merging them immediately. I have this
piece of code that allows me to very effectively manipulate a list of
rectangles and do all kind of operations on them (xor, offset,
difference, union etc.). One possibility for the API in NSView would
be:
- (void)drawRects:(NSXXXX *)rects { // Don't know if we are going
to expose a new class or simply use a NSArray
[self drawRect:[rects bounds]];
}
- (void)drawRect:(NSRect)rect {
....
}
-drawRects will be called instead of drawRect. Up to you to override
it instead of -drawRect: to iterate through all the rectangles.
Maybe the time has come to finally do something about it?
Regards
Ian Clark
DrawWell Technologies Ltd.
www.drawwell.com