[patch] ElementCompositorService: emit custom notification after finalization of compose() / decompose
Currently, the performance of the annotation view (and probably also
other views that use a org.eclipse.emf.common.notify.Adapter
s to
listen for model changes, have a very poor performance in the following
cases:
- Addition of large sub-models (typically, via copy’n’paste)
- Removal of large sub-models (typically, removal of an element at the top of the hierarchy)
Analysis:
- This is because EMF will issue a
Notification
of typeNotification.ADD
/Notification.REMOVE
for any model element that has been added / removed to the model. - However, for an efficient update of the GUI, it would be sufficient to be notified after the entire operation has finished.
- At least in the case of removal, the problem cannot be worked around by ignoring some events bases on previously received events, because the recursive implementation of org.fortiss.tooling.kernel.internal.ElementCompositorService.decompose() performs the removal button u Hence, the events for the elements at level n are received before the events for elements at level n –1, etc.
Proposed solution (see attached patch):
- Issue a custom notification in
org.fortiss.tooling.kernel.internal.ElementCompositorService.(de)compose()
which can be observed by views (instead of
Notification.ADD
/Notification.REMOVE
). - The patch uses
org.fortiss.tooling.kernel.utils.EcoreUtils.postRefreshNotification()
, but also a dedicated event could be created (e.g., KERNEL_MODEL_COMPOSITION / KERNEL_MODEL_DECOMPOSITION).
Test case: see attached model
- Open annotation view
- Open model and ensure that the annotation view is populated with it
- Delete any of the component
root1
,root2
,root3
- Observe the the removal takes very long without the patch
@ Flo / Vincent: Can you please have a comment?
(from redmine: issue id 2183, created on 2014-12-11)
- Uploads: