Hi, Benoit,
I can’t claim to have observed performance problems because I don’t work with diagrams of any appreciable scale.
However, this stereotype notation has caused problems in the reliability of undo/redo: unprotected writes in the notation model break the integrity of a transaction’s change descriptions. We’ve made some rather risky fixes to address some known undo errors, but I don’t know that there aren’t more problems of that kind waiting for us.
Personally, I would much rather see the CSS engine enhanced with synthetic attributes for the diagram shapes that control the presentation of applied stereotypes without having to create these views in advance and “just in case.” But, I’m not sure how the creation of those applied-stereotype views via the CSS can be done safely from a transaction/undo-redo perspective even in this case: CSS changes happen outside of the model and its transaction context. And this is assuming that the only reason for the current design is to support CSS; I can’t make that assertion.
Sorry, I don’t have any better answers than this.
cW On 6 September, 2016 at 09:09:15, MAGGI Benoit (benoit.maggi@xxxxxx) wrote:
Hi Christian,
As usual, many thanks for the explanation and the link.
Still the problem remain, creating on the fly element just in case there might be a css rule on, it’s killing the performance on a model with a lot of stereotypes.
Is there anyone using the StereotypeComment feature that can share his point of view on that?
Does anyone is also experiencing performance issues on model with a lot of stereotypes?
Regards,
Benoit
My understanding is that the implementation of applied-stereotype presentation in the diagrams was changed in the Mars release from EAnnotations that tagged views with display
options to these hidden notation views in part because this allows CSS styling to interact with the visualization. Because CSS rules need to be able to drive the visibility and styling of all of the different kinds of views that present stereotype applications,
and because CSS can only operate on objects that exist, the diagrams create all of these views on-the-fly but hidden by default.
More background can be traced through this wiki page (I think):
On 2 September, 2016 at 09:07:36, MAGGI Benoit (benoit.maggi@xxxxxx) wrote:
Hi everyone,
I was looking for performance when opening a model.
My current use case: opening a SysML 1.4 IBD (20 element, contains element with stereotypes)
When opening the model the following class seems to consume a lot of time [1].
This method [2] seems to recreate a (stereotype) comment when refreshing.
I don’t display any StereotypeComment in my diagram and these comments aren’t serialized after closing the model.
Has someone an idea of why it’s creating a comment?
(I would expect to have the comment only created when the user want to use/display it)
Regards,
Benoit
1 : org.eclipse.papyrus.uml.diagram.stereotype.edition.editpolicies.AppliedStereotypeCommentEditPolicy
2 : refreshStereotypeCommentStructure
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|
