You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I post this issue for future reference. The title sounds bad but I actually don't think it is so important as it does not correspond to a typical usage of Gepetto-Viewer.
When iteratively deleting nodes then re-creating them, we observed that the memory usage of Gepetto-viewer keep growing.
Gepetto-viewer is typically used in situations where we want to avoid re-loading the visual objects, so this situation is unlikely to happen. A minimal answer is to take care of raising the user awareness when writing an application where nodes are systematically deleted. A second level of answer could be to add automatic warning in Gepetto-viewer itself, when observing unusual node deletion (say after 1000 deletions, emit a warning to the console). Of course, ideally, this bug should be fixed.
Note that it was only tested with XYZaxis features, maybe simpler visual objects are not causing it.
with more details ...
The bug can be observed with the following code:
importtimeimportosimportgepettoimportsys# Open the connection to gepetto viewertry:
viewer=gepetto.corbaserver.Client()
gv=viewer.guiexcept:
print("Error while starting the viewer client. ")
print("Check whether Gepetto-viewer is properly started")
sys.exit(-1)
# Open a window for displaying your model.try:
# If the window already exists, do not do anything.windowName='pinocchio'windowID=gv.getWindowID (windowName)
print("Warning: window '"+windowName+"' already created.")
print("The previously created objects will not be destroyed and do not have to be created again.")
except:
# Otherwise, create the empty window.windowID=gv.createWindow (windowName)
# Start a new "scene" in this window, named "world", with just a floor.gv.createScene("world")
gv.addSceneToWindow("world",windowID)
fortrialinrange(100):
print(f'Run {trial} !' )
foriinrange(100):
name=f'world/xyz{i}'gv.deleteNode(name,True)
gv.addXYZaxis(name,[1.,1,1.,1.],.01,.2)
gv.applyConfiguration(name,[i*.01,0,i**2*.001,0,0,0,1])
gv.refresh()
os.system('free -h')
duration=1print(f'Now sleeping for {duration}' )
time.sleep(duration)
(you need to start gepetto-gui corba server first).
The memory raise is displayed on the following plot:
(this plot can be reproduced with pmap using https://gitlab.laas.fr/-/snippets/17 and lanching pmapnitor.py gepetto-gui then the script above.
The text was updated successfully, but these errors were encountered:
I have been able to reproduce the issue. However, when counting the number of nodes allocated by increasing a counter in each constructor and decreasing it in the destructor, the total number of objects at the end of the test is 105.
The problems does not come from nodes not being destroyed.
I post this issue for future reference. The title sounds bad but I actually don't think it is so important as it does not correspond to a typical usage of Gepetto-Viewer.
When iteratively deleting nodes then re-creating them, we observed that the memory usage of Gepetto-viewer keep growing.
Gepetto-viewer is typically used in situations where we want to avoid re-loading the visual objects, so this situation is unlikely to happen. A minimal answer is to take care of raising the user awareness when writing an application where nodes are systematically deleted. A second level of answer could be to add automatic warning in Gepetto-viewer itself, when observing unusual node deletion (say after 1000 deletions, emit a warning to the console). Of course, ideally, this bug should be fixed.
Note that it was only tested with XYZaxis features, maybe simpler visual objects are not causing it.
with more details ...
The bug can be observed with the following code:
(you need to start gepetto-gui corba server first).
The memory raise is displayed on the following plot:
(this plot can be reproduced with pmap using https://gitlab.laas.fr/-/snippets/17 and lanching
pmapnitor.py gepetto-gui
then the script above.The text was updated successfully, but these errors were encountered: