| Re: [mdt-papyrus.dev] [Performance] Css/stereotypes element creation |
|
Hi Christian, Thx for the answer. I wasn’t really going to remove everything anyway
J I made some small improvement (still in my draft) on Utility and EditPart but the problem remains pretty much the same. My performance problem is coming from the combination of our css engine and the calls to UML2 stereotype methods
-
Is there any way to cached the stereotypes application?
-
There is probably some works todo in StereotypeDisplayUtil to have less call to UML2 getstereotypeapplication (I hope to catch @Celine tomorrow to get
some ideas from her)
-
The main problem is still in the css engine
o
I found a way to override the default one for SysML 1.4 (so it shouldn’t impact other DSML)
o
I can also pass the notification from StyleListener to CSSEngine handler
§
Is there a way to differentiate an “open diagram” notification from a simple “create element” (both seems to use ADD event) ?
o
It should also be possible to use my own diagramHelper to customize the refresh (refresh only the created element)
§
Is there a nice way to do it? Regards, Benoit
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian Damus Hi, Benoit, I cannot comment on the refreshing of the applied-stereotype edit-part, but I do know some of the background about the CSS refresh. You probably would notice a regression in the refresh of the diagram visuals if you have CSS stylesheets in which the presentation of an element (for example its colours,
line styles, SVG shapes, etc.) depended on its relationship to other elements in the diagram and you change those relationships. For example, if a nested class has a different fill colour to classes in a package, then in a class diagram editor dragging a
class from the diagram surface into the nested classifiers compartment of another class, or vice versa, would not result in its colour changing. The TODO has been there since the very beginning of CSS support because the way the cache was initially implemented makes it difficult or impossible to target the styling
refresh to specific affected edit-parts; there is currently no way to determine the scope of CSS rules that are affected by any given change in the model. So, please do not comment this out! 😀 HTH, Christian On 25 July, 2016 at 10:24:31, MAGGI Benoit (benoit.maggi@xxxxxx) wrote:
|
