| The refresh performance of EditPart in Sirius [message #1792794] |
Tue, 24 July 2018 08:07  |
 jingjing wang
Messages: 28
Registered: July 2017 |
Junior Member |
|
|
I have a question about refresh performance of GraphicEditPart in Sirius, such as: the class of AbstractDiagramElementContainerEditPart, AbstractDiagramBorderNodeEditPart.
Actually, in our scene, there is a performance problem of invoking AbstractDiagramElementContainerEditPart.refresh() when doing ELK(Eclipse Layout Kernel) in the diagram. The code of AbstractDiagramElementContainerEditPart.refresh() shows as below:
public void refresh() {
super.refresh();
List<?> children = getChildren();
for (int i = 0; i < children.size(); i++) {
EditPart editPart = (EditPart) children.get(i);
editPart.refresh();
}
}
In our analysis, we find that the refresh operation of children edit part will be invoked in super.refresh(). So why it needs to invoke refresh operation chidren edit part after super.children() again?
In our scene, AbstractDiagramElementContainerEditPart.refresh() will be invoked when processing notification events which is caused by layout algorithm, such location change of the element. Acctually, the notification event is related with the element, has nothing to do with its children, so why we need to do its children edit part refresh? We try to remove the process of its children edit part refresh, the performance of AbstractDiagramElementContainerEditPart.refresh() has improved 50% in our scene.
There are two questions:
1) Is there any scene that must refresh its children edit part ? Can you describe it in detail?
2) If we remove its children edit refresh operation, are there any bad effects?
We will be very grateful if anyone can give us some related advise. Thank you very much!
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04086 seconds
] 
Search
Help
Register
Login
Home
