Re: is [uiObject display] necessary?
Re: is [uiObject display] necessary?
- Subject: Re: is [uiObject display] necessary?
- From: jgo <email@hidden>
- Date: Mon, 10 Dec 2001 12:08:55 -0800
>
at 2001-12-07 17:12:43 +0100 Marcel Weiher wrote:
>
> On Donnerstag, 2001 Dezember 6 at 04:54 Uhr, jgo wrote:
>
>> ??? 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.
If the needsDisplay characteristic has not been set, then the event
processing should not eat up time doing a display... unless the
system has decided to set it for one reason or another. So,
there's no inefficiency, no lost cycles. If I'm doing extraneous
updates, then that suggests need for reworking my code. If the
framework or OS decides to do an extraneous update, then that is
where the finger should be pointed at WRT inefficiencies. Of course,
after a series of displays it should force the pixels on-screen,
so, yes, I was simplifying to the same degree as the prior
post in the thread.
>
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.
That's not what I wrote. What I wrote was that the update should
occur at an appropriate point after a series of updates. Since the
time when the "automatic update cycle" does it is arbitrary &
unknown, these 2 times do not usually coincide.
>
-setNeedsDisplay: on the other hand works just as well as a single
>
update as it does in a series of updates.
No, it does not do it "just as well as a [specific] update" because
it does it at its whim, not "mine", which, hopefully, coincides
with the users'.
>
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.
Ahh, now here's a point to explore. In what way is one way of
handling this any more or less "brittle" than another. Since
a redraw & display are a single transaction, it makes sense for
it to be in a nice, neat, encapsulated unit that doesn't rely
on some far-flung process to be triggered by a stored flag.
>
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...
It's not "overhead" because it's something that gets done no matter
which of the proposed strategies is used.
John G. Otto, Eagle Scout, Knight, Cybernetic Praxeologist
Existence, Consciousness, Identity, Life, Liberty, Property, Privacy, Justice