Re: Coalescing Updates in MVC?

[Jeff Higgins]

On 05/24/2012 07:02 AM, Stefan Ram wrote:
> When a controller request many little changes of the model,
> it might make sense to update the screen not after every little
> update but only after the last update of the containing operation.
>
> However, the model or view do not know after a little model
> update whether there are more updates to come, so they
> cannot decide whether to update now or later. Also the model
> does not know whether an observer is a View or some other
> entity that possibly might need to be notified of each
> little update.
>
> How is this usually handled?
>
> I see one possibility to write the controller code as, e.g.,
>
> model.startCompoundChange();
> while( final Example example : container )model.add( example );
> model.endCompoundChange();
>
> Where »startCompoundChange« and »endCompoundChange« will then
> be broadcast to all observers of the model and the observers
> now are free to only refresh the display after an »endCompoundChange«.
>
> Another solution would be to send lightweight update
> notifications to the View which then will start a timer to
> update after, say, 0.1 s, ignoring all additional update
> notifications for the same model that arive during that
> time. But this might feel more sluggish to the end user,
> because the visual feedback is delayed.
>
See Cocoa's NSNotificationQueue.
Some discussion is here:
<http://www.mikeash.com/pyblog/friday-qa-2010-01-08-nsnotificationqueue.html>

[John B. Matthews]

In article <MVC-updates-2...@ram.dialup.fu-berlin.de>,

r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> How is this usually handled?

java.awt.Component coalesces certain mouse and paint events in
coalesceEvents(), which is called by EventQueue.postEvent().

When using javax.swing.Timer, isCoalesce() is true by default. In
practice, this degrades gracefully on slower hardware.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[Lew]

John B. Matthews wrote:
> Stefan Ram wrote:
>. . .

>> How is this usually handled?
>
> java.awt.Component coalesces certain mouse and paint events in
> coalesceEvents(), which is called by EventQueue.postEvent().
>
> When using javax.swing.Timer, isCoalesce() is true by default. In
> practice, this degrades gracefully on slower hardware.

I'm not sure coalescing model events is necessarily faster than processing
them, depending on how things are staged and parallelized.

An event-processor loop can detect that it has multiple events pending when it
tries to fetch one, and attempt to coalesce some before applying them to the
model. But then you sort of need to model the effects of each event to know
how they can coalesce, which is already the job of the model.

In the AWT case John mentions, it is view events that are coalesced. This
makes sense - the graphics engine has a model of the display with which it can
outpace the actual display using offscreen buffers and other tricks.

So the "M" part of the system applies its changes sequentially and atomically,
firing off change notifications but not actually changing the "V" part. The
model thus stays nimble and up to date. The "V" part is perforce slower, but
the processing engine can coalesce events if it's faster than the display.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[John B. Matthews]

In article <jpr9be$gg0$1...@news.albasani.net>, Lew <no...@lewscanon.com>
wrote:

As concrete examples of this helpful distinction, this example [1] uses
a view Timer to drive a deterministic model of a system evolving in
time. The update frequency is limited by the paint period. Eventually,
the Timer saturates and performance fails.

In contrast, this example [2] uses a model Timer to periodically notify
the view, which then takes a "snapshot" of the model as it evolves
independently in a separate thread.

[1] <https://sites.google.com/site/drjohnbmatthews/kineticmodel>
[2] <https://sites.google.com/site/drjohnbmatthews/threadwatch>