[mcclim-devel] question about display functions and control apps
Timothy Moore
moore at bricoworks.com
Wed Dec 29 10:37:54 UTC 2004
On Dec 28, 2004, at 10:41 PM, rpgoldman at real-time.com wrote:
> Actually, if I understand Hef's comments correctly (and I haven't
> misunderstood the kytron code), this isn't really the right model.
> The problem is that the kytron is still really a synchronously
> operating simulation: the sim does one step, then you call
> clim:redisplay-frame-pane, repeat.
>
> The problem with control apps, is that there will be a separate thread
> that will be latching state updates, and will not be working in synch
> with the UI. So you might get something unpleasant happening if you
> invoke clim:redisplay-frame-pane from that separate thread (assuming[1]
> that the clim redisplay function is not thread-safe).
>
>
...
> I hope that this design question is of sufficient generality to be of
> wide interest, and that I'm not wasting everyone's time....
>
... Not at all; this is an interesting issue that has occupied a lot of
my brain cycles without much success. A further complication is that
recording panes are not at all thread safe in McCLIM; I don't know
whether they are in Classic CLIM. It would be very nice to have a
simulation ---especially in 3D using OpenGL --- running in an
application pane while at the same time one could continue to use the
interactive command loop with typed commands, sensitive presentations,
etc.
McCLIM does have some nascent support for timer events, but this is way
below the level of command processing. One approach might be to extend
this to "throw" a redisplay command when a timer or other update event
arrives. Right now that would destroy the state of command line editing
in the interactor pane, so some work would have to be done to preserve
the state of the input editing stream. Some examples of how to do this
are in the accepting-values code in dialog.lisp.
The situation is not so dire because the easiest way to write a CLIM
application is to follow an MVC approach of update the model, redisplay
it, and let CLIM take care of optimizing the redisplay. That means that
the redisplay and the command processes --- the interactive command
loop, plus whatever else might change the state of the model -- could
operate asynchronously from each other as long as they use some kind of
mutual exclusion mechanism. An interactive command could cause the pane
to be redisplayed, or one might let the next timer event, vertical
retrace event or whatever force the redisplay. The remaining
complication, then, would be the handling of sensitive presentations
and pointer documentation. The CLIM command loop would have to know
about the mutex protecting the view and also be alerted that
presentations may have moved, appeared, disappeared, etc.
None of this is very helpful for an application developer wanting to do
something right now, but I hope it is food for thought for McCLIM
developers and users alike.
Tim
More information about the mcclim-devel
mailing list