We could have the FigClass listen to ALL modelevents that may cause a change
to its appearance (and not the compartment contents). Arrival of each such
event shall set a flag, and (if it is not already started) start a task with
Swing.invokeLater().
Any next event that arrives before the task has been executed, shall have no
consequence.
When the FigClass is removeFromDiagram()'ed, the flag may be cleared, which
causes the task to do nothing.
All the above on the the MDR event processing thread.
And, on the Swing/AWT event processing thread, when the task fires, it first
clears the flag, and then refreshes/redraws the whole class at once, by
querying the model.
I would prefer we still breakdown responsibility throughout the
composite pattern of Figs.
Our FigTexts should listen to model events (according to notation) to
update themselves.
FigCompartments should listen to specific add/remove events to update
themselves.
FigNodes should listen for delete events.
Why is this good:
Usually, changes come in packs - e.g. MoveUp of an Operation changes 2
operations by remove, add. Many model events only lead to redraw once.
Unless you may have a multicore uP, in which case an (probably one) extra
redraw does not do any harm anyhow. We can even build in a 100ms delay, if
that would help.
I do see what you're getting at.
e.g. the user edits an operation on the diagram changing its return
type and adding various parameters. The FigText then gets several
events back one after the other informing it of a change to the model
element it represents. For each one of these it will end up redrawing
itself.
Similarly for a compartment. If we do move up of an attribute then we
actually get a remove event followed by an add event. We redraw twice.
I don't know how much of a problem this is and I'm no great thread
expert myself but if we tackle this would we do better do start a new
thread for each of these.
e.g.
For a compartment, when the FigCompartment receive a new event of
interest it starts a new thread passing in that event. The duty of
that thread is to pause for some fixed amount of time and then process
that event.
However if the FigCompartment receives another event before the thread
has finished it calls that thread to give it a new event and its timer
start again.
When the timer completes with no new events it process those events in
one go and completes.
Bob.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
