Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.gui > #5155

Re: Coalescing Updates in MVC?

From "John B. Matthews" <nospam@nospam.invalid>
Newsgroups comp.lang.java.gui
Subject Re: Coalescing Updates in MVC?
Date 2012-05-28 23:30 -0400
Organization The Wasteland
Message-ID <nospam-9D9F5E.23301328052012@news.aioe.org> (permalink)
References <MVC-updates-20120524124948@ram.dialup.fu-berlin.de> <nospam-28098B.15535424052012@news.aioe.org> <jpr9be$gg0$1@news.albasani.net>

Show all headers | View raw


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

> 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.

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>

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

Back to comp.lang.java.gui | Previous | NextPrevious in thread | Find similar


Thread

Re: Coalescing Updates in MVC? "John B. Matthews" <nospam@nospam.invalid> - 2012-05-24 15:53 -0400
  Re: Coalescing Updates in MVC? Lew <noone@lewscanon.com> - 2012-05-26 12:02 -0700
    Re: Coalescing Updates in MVC? "John B. Matthews" <nospam@nospam.invalid> - 2012-05-28 23:30 -0400

csiph-web