Re: Ways Apple COULD optimize -setNeedsDisplay
Re: Ways Apple COULD optimize -setNeedsDisplay
- Subject: Re: Ways Apple COULD optimize -setNeedsDisplay
- From: Marcel Weiher <email@hidden>
- Date: Tue, 18 Dec 2001 17:56:39 +0100
On Dienstag, Dezember 18, 2001, at 05:34 Uhr, Erik M. Buck wrote:
The window display logic could just call each view's displayInRect: the
correct number of times for the number of invalid rects that must be
re-displayed.
I don't think this is such a good idea: a view might very well assume it
is only being refreshed once and (a) do some sort of expensive
conputation or (b) update its entire area, relying on the unecessary
parts being clipped away.
I like the idea of a -drawRect:(NSRect*)rects count:(unsigned)count
with the old NS 3.3 semantics that has a default implementation of [self
drawRect:rects[0]];
However, neither of these two are really all that important, the big one
is:
The real key is that views that do not need to be
re-displayed at all should not be displayed at all.
Exactly, and this is quite possible even with the current simplified API.
Right now, the entire
content of a window must be redrawn just because two small views on
opposite
corners of the window need re-display. This was definitely NOT
necessary in
Openstep 4.2 for Windows. We sell a high end animation application that
does not exhibit this ridiculous behavior.
I wouldn't be entirely surpised if Mac OS X Server 1.x doesn't display
this behavior either. A lot of damage was done after that, in the great
Carbon and CoreFoundation upheaval (though I don't quite see why this
had to get broken). Of course, the amazing thing remains that the folks
at Apple managed to pull this off at all. Now they have to get back to
making it work well...
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.