| [GEF4] Possible memory leak in SelectionBehavior.updateHandles() [message #1734938] |
Mon, 13 June 2016 23:16  |
|
I'm seeing a memory leak in my GEF4 editor, which I think is related to SelectionBehavior.updateHandles().
In case it's not clear from my previous posts, my application is a map editor. The user can draw various terrain features like hills, rivers, roads, forests etc. Most of the terrain types store the model as a Path-like structure, i.e. a list of segments representing lines or curves. For example, a river will be composed of a list of cubic curves, which will be converted to a PolyBezier and rendered with a GeometryNode.
To draw a feature, the user selects the appropriate creation tool, then clicks on the waypoints of the feature, so you end up with a model object composed of a sequence of points, with control points in between to manage the curves. To edit a shape, the selection policy will create a selection handle at each waypoint, and another selection handle at each control point. Dragging the control point handle will change the shape of the curve.
In the control point's on drag policy, I call SelectionBehavior.updateHandles() after the operation is committed, so that the selection handles get updated with the new model locations. However, this seems to be causing a memory leak. I noticed that the application memory grows continuously as you add shapes, and much more rapidly than I would expect just from the model objects and parts.
Creating a large shape might involve a few hundred operations, so my first thought was that the operation history might be behind it. I made sure that the application clears the undo operation history on saving the application, but a save does not reduce the application's memory at all.
I had a look at the memory using the Eclipse Memory Analyzer, and the issue seems to be that the selection handle parts stick around in memory somewhere, I think AdaptableScope. The memory profile showed that AdaptableScope was responsible for about 53% of the heap size. The object counts also showed that there were tens of thousands of instances of my selection handle parts and their associated objects like StaticAnchor, when at the time I took the snapshot, the selected part had about 110 handles active.
Looking at SelectionBehavior.updateHandles(), I see that it calls AbstractBehavior.switchAdaptableScopes, so I am guessing that the problem is somewhere in there, although it may also be it the selection observer that removes and adds the feedback and handles when the selection changes. Any thoughts?
Colin Sharples
CTG Games Ltd
Wellington, New Zealand
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03250 seconds
] 
Search
Help
Register
Login
Home
