Morphic damage management - how does it work?
Last updated at 3:30 pm UTC on 14 January 2006
Question: How does Morphic damage management work?
From Ross Boylan Sent: 8 January 2003
I keep experiencing odd failures in the [Morphic View] invalidation code. My application has a thread that ticks away and causes some updates to the display. It may be relevant that the errors are being raised from that thread, rather than my main thread ..
This is a weird error.
From: Ned Konz Sent: 8 January 2003
Morphic is single-threaded. But it looks like you're invalidating Morphs from a non-UI thread. Doing this can cause problems, as you've found. The assumption in the code is that the DamageRecorder is accessed from a single thread, at the right time.
If you really want to update Morphs from a background thread, I'd recommend
WorldState addDeferredUIMessage: valuableObject
where valuableObject is usually a BlockContext or MessageSend (anyway, something that can respond to #value)
Or use a SharedQueue and call #nextOrNil on it from a regular #step message (in the main UI thread). This queue would have data or instructions (like, perhaps, MessageSends) that would specify how to change the morphs.
Oh my. That certainly clears things up, and thanks for the suggested fixes. They should be easy to do. Why is Morphic single-threaded?
The standard multi-threading in Morphic is through the step and alarm methods. You can register step methods that will get called periodically at the appropriate times from the UI task. You can also register for a one-shot alarm.
Note that you can have more than one step method active at a time, with different frequencies. (see step:at: and friends). So you're not limited to just using #step and #wantsSteps.