Hi Milad, mitk::LevelWindowManager::TreeChanged()
registers listeners to all "visible" properties of all nodes. Then it checks if the LevelWindowProperty of the node that it currently displays is still available. If not, it selects a new one. This code is quite old and needs reworking. Maybe we could throw it away altogether and write a faster, leaner solution using the Selection Service of the new Qt4 based application (see http://bugs.mitk.org/show_bug.cgi?id=2992). But we will probably not change it for the old Qt3 based application. If you want to stick with that, you need to find your own solution. If you don't need Level/Window functionality, maybe you could just remove it altogether. Regards, Jochen > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] > Gesendet: Montag, 16. November 2009 18:38 > An: Neuhaus Jochen > Cc: '[email protected]' > Betreff: Re: [mitk-users] Performance problem with > CommonFunctionality::AddVtkMeshToDataTree() > > Thanks Jochen for your quick reply. > > I did some more investigations. Actually, more than 50% of the CPU-time > is consumed by mitk::LevelWindowManager::TreeChanged(). This method is > called whenever a new node is added to the tree. > To be honest, I did not understand really what the > LevelWindowManager-class is about and what the TreeChanged()-method > does > but the documentation says "TreeChanged() > <http://docs.mitk.org/0.12/classmitk_1_1LevelWindowManager.html#b2e2b6b > 2c31cc5109c62c1cc76b72ba9> > listens to the DataTree > <http://docs.mitk.org/0.12/classmitk_1_1DataTree.html> for new or > removed images". This surprised me because I am just showing one image > which is loaded at program's startup. So images should not be > responsible for the performance-problem. > > Can someone give me please a short explanation what > mitk::LevelWindowManager::TreeChanged() does so I can judge whether I > need it at all. > > And a small request: As a developer I would be very happy about more > detailed class-documentations in the next versions of mitk (or at least > some comments in the method-bodies). Its quite hard to understand what > the (internal) classes are doing. > > Thanks, > > Milad > > Neuhaus Jochen wrote: > > Hi Milad, > > > > - one way to optimize performance would be to write your own custom > data class and then write a custom 3D mapper for it that handles the > VTK objects more efficiently. > > > > - you could try to upgrade to our new Qt4 based application, which > uses a new map based data structure to store and retrieve objects > (although it has not been optimized for performance with a large number > of objects). > > > > - finally, you could try to get a DataTreeIterator (each > functionality has one) and use that to add objects to the DataTree. See > http://www.itk.org/Doxygen316/html/classitk_1_1TreeIteratorBase.html > for how to add nodes using an TreeIterator > > > > Regards, > > Jochen > > > > ________________________________________ > > From: Milad Sadinam [[email protected]] > > Sent: Monday, November 16, 2009 2:49 PM > > Cc: '[email protected]' > > Subject: [mitk-users] Performance problem with > CommonFunctionality::AddVtkMeshToDataTree() > > > > Dear all, > > > > I am developing a plug-in for mitk 0.12.2 (with QT 3) using VTK-5.2.1 > > and ITK-3.8.0. > > In my program I render rather simple objects (most are spheres and > > cubes) but the number of the objects is quite high (about several > > hundreds). > > Now, I encountered serious performance problems during data-loading > and > > also during normal program running (as I often create and remove > > dynamically objects to be rendered). > > > > A typical way how I create a object for rendering looks like this: > > vtkSphereSource* sphere = vtkSphereSource::New(); > > CommonFunctionality::AddVtkMeshToDataTree(sphere->GetOutput(), > > > > this->GetDataTreeIterator(), > > "node-name"); > > > > Running a profiler showed me that > > CommonFunctionality::AddVtkMeshToDataTree() is the bottleneck of my > > program. > > I went with the profiler deeper into that function and it seems to me > > that a great chunk of the time is consumed by tree-operations like > > itk::TreeNode<>::ChildPosition() or > > itk::SmartPointer<itk::TreeNode<void<mitk::DataTreeNode> > > > >::operator==<const void<mitk::DataTreeNode>*>(bool, > > mitk::DataTreeNode) const. > > > > I am not sure whether I interpret this correctly. Is the problem > really > > the high number of objects and the from this resulting data-tree > > handling-code? > > Is there another (faster) way how I can create high number of > objects? > > I am not sure what AddVtkMeshToDataTree() exactly does. What are > > important criterias to increase its performance? > > > > Many questions....hope you can help me with them :-) > > > > Milad Sadinam > > > > > > > > --------------------------------------------------------------------- > --------- > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > > trial. Simplify your report design, integration and deployment - and > focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > mitk-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mitk-users > > > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
