Forgive me for not including code but there are like 6 classes where all of this is contained in and some are several hundred or more lines long, its just not feasible
I have run into an interesting issue where Matlab begins to eat up memory essentially doing little more than updating an Axes object CurrentPoint property from a uipanel button down function. At least so far as I can tell.
I have a GUI class with a uipanel object that has an axes object a child. The uipanel's buttonDownFcn is a mainViewPan function that uses a persistent variable to store the axes CurrentPoint property from a previous call and uses the CurrentPoint value from this call to recompute the axes XLim and YLim values.The end effect is a dragging/panning behavior where one can move around in the axes space.
Now on this axes object are a number of surfaces. Each surface comes from a surface display class object and each of these display objects also has a surface data class. The structure looks like this:
DisplayClass * has a* matlab primitive surface object and * has a* SurfaceDataClass, both as handles.
SurfaceDataClass has the surface cData as a property so in the DisplayClass hSurf.cData is set from DisplayClass.SurfaceDataClass.data.
These are all handles and there is a bunch of linking with listeners to ensure everything stays up to date.
In the same GUI class where the axes and uipanel exist for display there is an array of these display class objects being managed.Now my original thinking was that there were issues with not properly deleting handles or the memory was being consumed by the amount of srufaces, their cData, and the overhead and replication of cData with these classes. So I implemented a bunch of schemes to save the image data to disk and reload it only when the surface objects are within the field of view (within XLim and YLim) and to delete the surface objects in a similar fashion. So effectively there is no data and are no surface objects when they are outside of the axes lims.
This works and I can confirm that all these objects are deleted. However this has no effect on the amount of memory used, it remains very high. What I discovered was that even If I leave all of these surfaces with their cData rendered on the axes the memory usage actually only drops when I "close" the GUI window. However, my "close" function doesn't actually close or delete the containing figure window, nor does it delete any of the surface objects or their data. It just sets the Visible flag of the figure to 'off'. So even though the data structures are all there in memory the memory usages drops considereably (8gb usage to 3gb usage).
Even more interesting when I re-open the figure by setting Visible to 'on', all of the surfaces are still rendered with their cData but the memory use does not go back up. This seems to indicate that it has little to do with the data in the axes, the surfaces, or handles being improperly dealt with.
Lastly, I found that I can reproduce the memory issue but simply "panning" around in my axes - that is by repeatedly firing the function to update the XLim and YLim. However, its only really noticeable if I have lots of surfaces displayed.
It seems to me that is a memory issue in "re-rendering" surfaces at different locations on screen. Is anyone familiar with this or have any ideas?