Comment 1 Esteban DUGUEPEROUX 2014-11-21 08:00:43 EST

A draft of gerrit : https://git.eclipse.org/r/#/c/36836/

Comment 2 Esteban DUGUEPEROUX 2014-11-21 10:08:28 EST

Comment 0 was incorrect, it sould be : 

Move GMF diagram refresh at the end of DDiagram refresh to avoid a GMF diagram refresh from precommit.

Comment 3 Esteban DUGUEPEROUX 2014-11-24 09:46:49 EST

Bug 439871 with commit 659094a72ead188dd29922efe31e2cc07e28e02a has created canonicalSynchronizerFactoryOverride to invoke GMF canonical refresh from non ui plugin. This will become useless with this task, move GMF canonical refresh in DDiagram refresh.

Comment 4 Esteban DUGUEPEROUX 2014-11-24 10:31:36 EST

To have canonical refresh independant of UI, we must :
1. Have D*EditPart.VISUAL_ID/MODEL_ID constants defined in non ui part
2. Have AbstractCanonicalSynchronizer/DDiagramCanonicalSynchronizer independant of EditPart and Draw2d

Comment 5 Pierre-Charles David 2014-12-04 10:31:54 EST

Please explain *why* you think this is needed/a good idea.

* Is it a question of performance? If so, give numbers and a reliable way to measure the problem and the impact of any proposed solution;
* Is it because of bugs caused by the current state? If so, which bugs?
* Is it because it would be cleaner in terms of architecture/modularity (as hinted by comment 4)?

Note that I'm not saying it is not a good idea, but to evaluate the priority of this we need a clear justification.

Comment 6 Esteban DUGUEPEROUX 2014-12-04 11:30:18 EST

This bugzilla was initially created with Bug 452558 to avoid precommits be called several times.

For this bugzilla, it is no more an issue about performance since Bug 452558 is fixed.

Now It is more about architecture/modularity improvement. Currently GMF diagram refresh is called only when a diagram editor is opened. If GMF diagram refresh was called directly in the DDiagram refresh we could avoid case of DDiagram model refreshed with not refreshed GMF diagram.
In addition we could have a headless GMF diagram refresh.

Having GMF diagram refresh, i.e. DDiagramCanonicalSynchronizer, managed directly in DDiagram refresh, i.e. DDiagramSynchronizer, we could have a more smart GMF diagram refresh. For example having a map from DDiagramElement to GMF View, DDiagramSynchronizer could add/remove/refresh directly the related GMF View instead of having DDiagramCanonicalSynchronizer recursively check which View should be added/removed/refreshed.
With this last point we could have better performance but to measure performance improvement, we must have a GMF diagram refresh independant of draw2d before.