I don't know who else uses GEF, so it's hard for me to judge whether Bob's suggestion of adding synchronization to it is a good idea. I suspect that most applications do all their drawing on a single thread, so this would be unnecessary overhead (although the proposed change to the drawing loop seems like a useful improvement).
Michiel's discussion about granularity of redrawing is really orthogonal to what thread the drawing occurs on, but I believe, as I think I've said before, that we should use a minimal update strategy (i.e. only redraw what changed). If there are cases where the complexity of the update code outweighs the benefit (e.g. State), then we can redraw that entire figure as a special case, but we shouldn't generalize the special case. Most of the time, the change is very straightforward and clear. If we get an event like: Type: AttributeChangeEvent Attribute: name OldValue: "OriginalName" NewValue: "NewName" it doesn't take a whole lot of "dissecting" to figure out what to do and it certainly doesn't require us to query all the stereotypes, attributes, operations, receptions, parameters of the operations, types of the parameters of the operations, etc and then rebuild the whole figure from scratch. Currently we update names on a per-character basis (another wasteful practice), so all of this is going on every time the user presses another key. Over time we seem to have moved to redrawing more and more, making ArgoUML less and less efficient. This seems to me to be the wrong direction and I'd hate to see us continue. Do we have an easy way of looking up what Figs contain a representation of a particular model element? I know we can go from Fig to ModelElement, but if we could also easily go the other direction, that might provide an easy way to process updates. A simple short term fix to the synchronization problem could be to have the Model event listener simply requeue the event for the Swing event thread using invokeLater(). I'm not sure how big a performance impact this would have, but if we did it conjunction with removing the delivery of duplicate (mirrored, actually), events, it might be a wash from a performance point of view. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
