| Lost memory while DnD [message #204065] |
Wed, 30 November 2005 02:16  |
Eclipse User |
|
|
|
Originally posted by: PhilippMarx.gmx.de
Hello,
in my graphical editor you can drag around the shapes. If you drop them on
another shape, they are connected to this shape. After the drop I update
my model, and set the changed model as the new input of my graphical
viewer (I need to do the update due to performance issues, so I cant just
update the views).
My problem is that after each drag there must be somewhere references to
the old views, editdomain or whatever. I am loosing about 10mb of heap
every drag. 10mb is about the size of my diagram objects (as I analyzed
with a profiler).
If I perform a drag in my outlineview there is no heap memory lost (there
the graphical representation is updated and not replaced).
So anybody knows what the problem could be?
PS: I am using the DragEditPartsTracker from the
AbstractGraphicalEditPart.
thx in advance
|
|
|
|
|
|
| Re: Lost memory while DnD [message #204285 is a reply to message #204240] |
Thu, 01 December 2005 13:31  |
| Eclipse User |
|
|
|
"CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> schrieb im
Newsbeitrag news:dmn0ob$9kv$2@news.eclipse.org...
> Philipp Marx wrote:
> > Yes the operation is undoable.
> >
> > I create a complete new model and set it as the new content via
> > GraphicalViewer#setContent.
> > I need to do so because of performance issues. I tried the other way
> > with updating the model, but this takes far longer, than setting a new
> > content. The problem is that I got about 15.000 graphical elements,
> > which are shown in a structured layout. If I add a new element in
> > between somewhere, nearly the whole diagramm needs to be redrawn. And
> > this goes faster with setting a new input.
> >
>
> Maybe you should reconsider what model is your root model. I still
> thing its worse performance wise to change the editor input just because
> the model changed.
>
> Anyway, when you make this change be sure to flush the command buffer
> since after the change the undoable actions are no longer undoable, are
> they?
>
>
> CL
No,
the model-objects are always the same. There is only a of
"father-son"-relaitionship changing on a drag. What I meant by setting a new
content is, that the old model is "again" set as the new content of the
graphical viewer. As I said I tried the other way via updating the views,
but it took far longer.
The commands are undoable afterwards, because they know about the changes in
the model (which is always the same).
This works out pretty good for all other actions I do, like Cut and Paste,
etc. When I cut an element, I do the same as I do when dragging (delete the
element from the model, and setting the model as the new content). There are
never any memory losses.
When I profiled the heap while dragging, I figured out that the number of
views and editpart is increasing every time I perform a drag. My own command
and action do not hold any references to those views and editparts.....
PM
|
|
|
|
| Re: Lost memory while DnD [message #204408 is a reply to message #204285] |
Fri, 02 December 2005 09:40 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Philipp Marx wrote:
> "CL [dnoyeb] Gilbert" <Lamont_Gilbert@rigidsoftware.com> schrieb im
> Newsbeitrag news:dmn0ob$9kv$2@news.eclipse.org...
>
>>Philipp Marx wrote:
>>
>>>Yes the operation is undoable.
>>>
>>>I create a complete new model and set it as the new content via
>>>GraphicalViewer#setContent.
>>>I need to do so because of performance issues. I tried the other way
>>>with updating the model, but this takes far longer, than setting a new
>>>content. The problem is that I got about 15.000 graphical elements,
>>>which are shown in a structured layout. If I add a new element in
>>>between somewhere, nearly the whole diagramm needs to be redrawn. And
>>>this goes faster with setting a new input.
>>>
>>
>>Maybe you should reconsider what model is your root model. I still
>>thing its worse performance wise to change the editor input just because
>>the model changed.
>>
>>Anyway, when you make this change be sure to flush the command buffer
>>since after the change the undoable actions are no longer undoable, are
>>they?
>>
>>
>>CL
>
>
>
> No,
>
> the model-objects are always the same. There is only a of
> "father-son"-relaitionship changing on a drag. What I meant by setting a new
> content is, that the old model is "again" set as the new content of the
> graphical viewer. As I said I tried the other way via updating the views,
> but it took far longer.
> The commands are undoable afterwards, because they know about the changes in
> the model (which is always the same).
> This works out pretty good for all other actions I do, like Cut and Paste,
> etc. When I cut an element, I do the same as I do when dragging (delete the
> element from the model, and setting the model as the new content). There are
> never any memory losses.
>
> When I profiled the heap while dragging, I figured out that the number of
> views and editpart is increasing every time I perform a drag. My own command
> and action do not hold any references to those views and editparts.....
>
> PM
>
>
>
>
>
Well all I can say is I think you are taking the wrong approach. You
should not be changing the editor input. If you do that you should be
dumping the command buffer. The command buffer likely holds onto your
old models as it needs them to undo stuff. so that would explain your
extra memory.
You should find another way to make the visual update faster than
swapping out the model. Perhaps you need a different 'root model' and
you can just change the child of the root model so you dont have to
change the editor input. I don't think the architecture will continue
to be friendly to the way you are changing your editor input. Its sort
of against the grain IMHO.
CL
|
|
|
Powered by
FUDForum. Page generated in 0.48927 seconds
Home