Re: is [uiObject display] necessary?
Re: is [uiObject display] necessary?
- Subject: Re: is [uiObject display] necessary?
- From: Marcel Weiher <email@hidden>
- Date: Fri, 7 Dec 2001 17:12:43 +0100
On Donnerstag, Dezember 6, 2001, at 04:54 Uhr, jgo wrote:
When you do need to make something refresh, you call
[icon setNeedsDisplay:YES], allowing the system to
aggregate display calls.
I've never been comfortable doing this, leaving the system or
quantum mechanics or spirits from another plane to determine when,
if ever, it gets around to actually applying the updates. Sure,
if I'm updating a series of things, it makes sense to have the
re-drawing done after the series. But most of the time, I want
to make the change and immediately have it done.
This sounds very reasonable, which is why I think I should take the time
to point why it is wrong.
My question would be when the frameworks/system might get
bent out of shape when I issue the display message.
There are several reasons why this approach is wrong both in general and
in particular, at least in the context of Cocoa.
1. Incorrect reasoning
Using -setNeedsDisplay: has nothing to do with spirits from another
plane, but follows the standard event-response-update cycle that Cocoa
implements. With Cocoa, -setNeedsDisplay: is the default method,
-display the exception.
Furthermore, doing the display immediately will not actually show
anything on screen unless you also flush the window and/or the context,
but this will cause performance problems because the event loop will
likely flush the window again. So using -display is neither simpler,
nor more direct without even more extra work.
2. Fighting the framework and doing too much work
Even though you did a display update yourself using -display during
event-handling, the Cocoa event loop will still do its update-processing
afterwards. So your application will be doing extra, unecessary work.
You might think that using -display is somehow 'more direct', but it
isn't.
3. Fragile code / modularity
As you yourself pointed out, waiting for the automatic update cycle is
better when several updates need to be performed. This means that your
direct-display update code makes an assumption about its environment (no
other updates) and will need to be changed if that assumption ever
changes.
-setNeedsDisplay: on the other hand works just as well as a single
update as it does in a series of updates.
I don't quite see the rationale for making your code more brittle
without any gain, especially since you don't necessarily have full
control over what other updates may be occuring.
4. Performance
As I've pointed out, your solution will suffer from inferior
performance. -display needs to do significant processing to set up the
view hierarchy for drawing, focusing on each view in the view-stack in
turn. This additional overhead, which can easily be more significant
than your actual drawing time, will be incured each time you call
-display, so the more non-coalesced updates you have (see above), the
worse it gets.
Apart from doing to much work on each update, direct-updating may also
lead to far too many updates. For example, my TextLightning PDF -> RTF
converter draws a status bar that also shows pages-processed vs. total.
At first I updated the current-page number directly (like you propose)
as I was processing, but I soon found that this was taking a significant
amount of the total CPU time (20-30%), because it was by then running at
quite a few pages/second even on my trusty old G3/233.
The reason I was doing direct updates was that the converter isn't
really an app with an event loop, but rather a filter-service that runs
straight through like a UNIX tool. Changing the app from direct-update
to a timed update strategy (instead of drawing +flushing ever page
number as it comes up, the number is updated every half second, if
necessary) essentially removed that overhead.
Cocoa essentially gives you that for free. It could, for example, delay
updating the screen, if it notices it gets behind on handling events, or
if a series of events are coalesced due to scripting or undo/redo
processing. If you force the display, you disable all that.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.