On deferred actions

Hello all,

Offline correspondence with Ian lead to an idea: rather than worrying about
whether deferred actions are processed in a timely manner, one perhaps could
simply limit their purpose.  A half-baked version of it would be to use them
to invalidate (not update - which might be a problem) and to treat the
invalidations like Windows treats paint messages: have at most one targeted
at any UI element, combining new ones into it rather than stacking them.
There might also be a need, or at least a befit, to "expire" them if a
redraw already occured.

Comments?  Let 'em rip :)

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

> would be to use them to invalidate (not update - which might be a
> problem) and to treat the invalidations like Windows treats paint
> messages: have at most one targeted at any UI element, combining new
> ones into it rather than stacking them. There might also be a need,
> or at least a befit, to "expire" them if a redraw already occured.

I did something similar once when I was dealing with large numbers of defered
actions.  Somthing like:

    onWhatever
        needsUpdate ifFalse:
            [needsUpdate := true.
            self defer: [needsUpdate := false. self update]].

There was probably a Mutex in there too (at least I hope so!).

It worked well enough for my purposes.  It *didn't* reduce the updates to the
logical minimum -- it'd tend to do three or four where before it'd been doing
batches of hundreds -- but it was close enough for my needs.

    -- chris