Difference between revisions of "AHM2012-Slicer-Architecture"

From NAMIC Wiki
Jump to: navigation, search
Line 4: Line 4:
 
== Displayable Managers ==
 
== Displayable Managers ==
  
−
* '''Displayable manager''': Specialized logic handling both '''RenderWindow <-> MRML''' and '''RenderWindow <-> Logic''' interactions.
+
* '''Displayable manager''': Specialized logic handling both ''RenderWindow <-> MRML'' and ''RenderWindow <-> Logic'' interactions.
  
 
* '''Motivation''': Have a well-designed mechanism to ...
 
* '''Motivation''': Have a well-designed mechanism to ...
−
** ...''represents'' MRML node within a Renderer/RenderWindow.
+
** ...''represent'' MRML node within a Renderer/RenderWindow.
 
** ... handle mouse/keyboard interaction.
 
** ... handle mouse/keyboard interaction.
 
** ... synchronize widget across different views.
 
** ... synchronize widget across different views.
  
−
* Usually a displayable manager is configured after its associated node(s) have been added to the scene. Later on, if the given node(s) are modified, the displayable manager will react accordingly.
+
* '''Usual scenario''':
−
 
+
** Each time a viewer is instantiated, this one asks a factory to provide him with a DisplayableManagerGroup.
−
* Each time a viewer is instantiated, this one asks the factory to provide him with a DisplayableManagerGroup.
+
** DisplayableManagerGroup contain a list of DisplayableManager
−
 
+
** Each DisplayableManager is associated with a Renderer and an InteractorStyle
−
For that reason, adding a method with the signature like "GetDisplayableManagerGroup()" doesn't "fit" the API. A method like "GetDisplayableManagerGroup(const char* MRMLViewNodeId)" could be added instead. It's also important to note that the factory doesn't have the ownership of the group, it means than a smart or weak pointer should be used.  Finally, I would rather prefer the factory remains a factory and doesn't manage groups.
+
** Displayable manager is configured after its associated node(s) have been added to the scene.
 +
** Later on, if the given node(s) are modified, the displayable manager will react accordingly.
  
 +
* '''Factory''':
 +
** [https://github.com/Slicer/Slicer/blob/master/Libs/MRML/DisplayableManager/vtkMRMLThreeDViewDisplayableManagerFactory.h vtkMRMLThreeDViewDisplayableManagerFactory]
  
 
Indeed, the API is very similar, both the (1)ThreeD and (2)Slice DisplayableManager derive from vtkMRMLAbstractDisplayableManager.
 
Indeed, the API is very similar, both the (1)ThreeD and (2)Slice DisplayableManager derive from vtkMRMLAbstractDisplayableManager.
Line 30: Line 33:
 
  - in term of readability should be very low. Indeed, you will have a Annotation base class for ThreeD and other one for Slice DisplayableManager. And it would be very clear to understand which object is responsible to do what ..
 
  - in term of readability should be very low. Indeed, you will have a Annotation base class for ThreeD and other one for Slice DisplayableManager. And it would be very clear to understand which object is responsible to do what ..
 
  - in term of line of code .. is more important ! But considering modern code editor and efficient c++ pre-processor/compiler .. things should go smoothly :)
 
  - in term of line of code .. is more important ! But considering modern code editor and efficient c++ pre-processor/compiler .. things should go smoothly :)
−
+
 
 
== Views and Layouts ==
 
== Views and Layouts ==

Revision as of 07:18, 10 January 2012

Home < AHM2012-Slicer-Architecture

Modularization Object Specialization

  • Slicer is build on top re-usable and tested libraries.

Displayable Managers

  • Displayable manager: Specialized logic handling both RenderWindow <-> MRML and RenderWindow <-> Logic interactions.
  • Motivation: Have a well-designed mechanism to ...
    • ...represent MRML node within a Renderer/RenderWindow.
    • ... handle mouse/keyboard interaction.
    • ... synchronize widget across different views.
  • Usual scenario:
    • Each time a viewer is instantiated, this one asks a factory to provide him with a DisplayableManagerGroup.
    • DisplayableManagerGroup contain a list of DisplayableManager
    • Each DisplayableManager is associated with a Renderer and an InteractorStyle
    • Displayable manager is configured after its associated node(s) have been added to the scene.
    • Later on, if the given node(s) are modified, the displayable manager will react accordingly.

Indeed, the API is very similar, both the (1)ThreeD and (2)Slice DisplayableManager derive from vtkMRMLAbstractDisplayableManager.

The differences are that:

(1) deals with MRMLViewNode / ThreeDInteractorStyle

(2) deals with MRMLSliceNode / SliceInteractorStyle

And again, the overhead: 

- in a term of efficiency should be limited since displayable manager can be registered on demand
- in term of readability should be very low. Indeed, you will have a Annotation base class for ThreeD and other one for Slice DisplayableManager. And it would be very clear to understand which object is responsible to do what ..
- in term of line of code .. is more important ! But considering modern code editor and efficient c++ pre-processor/compiler .. things should go smoothly :)

Views and Layouts

Retrieved from "https://www.na-mic.org/w/index.php?title=AHM2012-Slicer-Architecture&oldid=73142"