| elegant way of solving performance problem with big diagrams [message #203585] |
Thu, 28 August 2008 09:25  |
 Seweryn Niemiec
Messages: 80
Registered: July 2009 |
Member |
|
|
Hi
My diagrams can be very big in sense of number of nodes. This implies
two kinds of problems: a screen refresh time and a diagram loading time.
For now, much more important problem for me is the screen refresh time.
Nodes form a recursive hierarchy with many levels (>5) of containment.
More or less it looks like a UML class diagram, where "Package" can have
"Package" and "Class" objects as it's children. "Class" object has its
own children (in my case 2 levels, sometimes hundreds of small children).
The good thing is that I don't want to display all nodes in the same
time (that would be useless), so the solution to this problem boils down
to developing a method of not showing some of the nodes - in my case:
children of the Class node, which are most CPU consuming.
It would be perfectly, to have something like this:
1. enable diagram partitioning on Package-subPackage relationship
2. a Package which is shown on the diagram as a TopNode shows only one
level of its children in a compartment: Packages and Classes without
theirs children
3. a Package which is shown as a diagram Canvas, shows its children with
all sub-children (with comply of point 2)
I have such diagram editor and it works fine until you want to move a
Class from Package to Package. Since Copy&Paste doesn't work (at least
in GMF 2.1) and Drag&Drop doesn't work too (see bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=245287 + you can't DnD
between editors) this makes whole thing quite useless. Currently the
only way to move Classes between Packages this to: close diagram editor,
open EMF editor, move Class, open diagram editor which using canonical
edit policy will update notation model (but original nodes layout will
be lost)
Do you create editors for very big diagrams? If so, how do you solve
screen refresh time problem?
Or maybe someone has another idea how to not display all levels of
containment?
Greetings,
Seweryn
PS. sorry for my English
|
|
|
|
|
|
|
| Re: elegant way of solving performance problem with big diagrams [message #203913 is a reply to message #203658] |
Fri, 29 August 2008 15:26  |
Eclipse User |
|
|
|
Originally posted by: thugcee.gmail.com
Alex Shatalin pisze:
> Hello Seweryn,
>
> Just for first time you can try moving domain model elements only. This
My first implementation of your idea used IEditorAction to do the job.
It was simple and it worked, so I've decided to jump into deep water and
try with DnD and Views persistence. After about 2h of debugging and
tracing the creation of CompoundCommands composed of tens of subcommands
(before .reduce()), I've found the place where I could hook my crappy
code. At the beginning it looked like messing with genes in DNA, where
small change in one place explodes with great number of unexpected
results all over the organism.
In my custom EP, lets call it PackageCompartmentEditPart, I have
installed CreationEditPolicy with overridden getReparentViewCommand
method. Originally this method creates a command which sets eContainer
of the dropped view to the view associated with EditPolicy's host.
I've just added in the middle a special treatment for the case when
Class is dropped into Package. Currently it is very specialized solution
and solves only problem with my model.
(My "Location" is our "Package" and a "Device" as a "Class")
@Override
protected ICommand getReparentViewCommand(
IGraphicalEditPart gep) {
View dropTarget = (View)getHost().getModel();
View view = (View)gep.getModel();
# check if we need special treatment
if (dropTarget.getElement() instanceof Location &&
view.getElement() instanceof Device) {
#we are looking for the Diagram which points to this sem. element
EObject dropTargetElement = dropTarget.getElement();
#probably this is not best method of greping diagrams
EList<Resource> resources = gep.getEditingDomain()
.getResourceSet().getResources();
boolean found = false;
for (Resource res: resources) {
for (EObject element: res.getContents()) {
if (element instanceof Diagram &&
((Diagram)element).getElement() ==
dropTargetElement) {
#we found our diagram, lets put it as a target for AddCommand
dropTarget = (Diagram)element;
found = true;
break;
}
}
if (found) break;
}
}
return new AddCommand(gep.getEditingDomain(),
new EObjectAdapter(dropTarget),
new EObjectAdapter(view));
}
The solution for the opposite direction should be simple too. I hope
someone will find it useful.
--
Greetings,
Seweryn
|
|
|
|
Powered by
FUDForum. Page generated in 0.03567 seconds
] 
Search
Help
Register
Login
Home
