Re: No regions, reason for Cocoa's inefficient window resizing?
Re: No regions, reason for Cocoa's inefficient window resizing?
- Subject: Re: No regions, reason for Cocoa's inefficient window resizing?
- From: Ondra Cada <email@hidden>
- Date: Sat, 14 Sep 2002 13:35:44 +0200
Since this issue occurred again, I'd like to again add my 0.2 cents worth:
I hereby reverse my previous very insistent assertion that
-setNeedsDisplay:
should be used in preference to -display whenever possible. The
opposite is
actually true.
Use -display rather than -setNeedsDisplay: whenever possible.
...
The use of -setNeedsDisplay is incorrectly advised several times in the
following
Actually, using -display instead of -setNeedsDisplay is still *wrong*, at
the very least
(a) whenever you happen to display the same rect more times inside of one
event loop (which is pretty probable);
(b) if and when the aforementioned Apple's howler is corrected;
(c) design-wise (it is not recommendable to fix an implementation bug by
crippling design).
There are better courses:
(i) ostrich fix
Don't do anything; just use -setNeedsDisplay, and bear the sluggishness.
Of course, this is not acceptable for apps which are graphically very
demanding, and where the Apple bug means the app is next to unuseable.
There is, on the other hand, relatively small number of such apps -- I
would estimate at most a quarter of all, probably much less. For the
majority, this is definitely the easiest solution.
(ii) inefficient, but very simple [see (iii) before you do that!]
Add an external bundle to your application, which can but need not be
loaded (preferrably due to a documented default), and which contains a
very simple "fix" of kind
// BEWARE -- UNTESTED!!!
@implementation NSView (YOURPREFIXFixAppleRedrawBugCategory)
- (void)setNeedsDisplayInRect:(NSRect)aRect {
[self displayRect:aRect];
}
@end
It would make the app just the same as if you explicitly used -display
directly instead of -setNeedsDisplay, but it would be easily switched off
as soon as possible (when either Apple fixes the thing, or a (iv) solution
occurs).
(iii) analogical solution, but a global one
Do more or less the same as in (ii), but make the bundle loadable to *any*
application (eg. using InputManagement, see Mike Ferris' TextExtras for
howto). Don't forget defaults so as the user is able easily to select
which apps should load the fix and which not.
(iv) final, good and nice solution
Prepare the bundle like in (iii), but re-implement there the displaying
behaviour of NSView properly, using a micro-tile array instead of the
dreadful current union rectangle.
I've considered adding this functionality into my OCSmart Hacks, but to be
honest I haven't time enough for that yet, and since my own applications
are not graphically intensive (and thus the (i) works for me excellently),
the urge was not strong enough ;) Nevertheless, happen anyone (Erik?) to
have the micro-tile code already prepared and debugged (so as it works
properly in all conditions, which is the main problem), I'd be glad to add
it to Hacks, so that anyone can use it.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.