///////////////////////////////////////////////////////////////////
r17884:
STYLE: Remove useless code in vtkMRMLModelNode

If the polydata is internally modified, there is no need to set the
polydata again to the model display. The polydata pointer has not changed,
this would be a no-op.

///////////////////////////////////////////////////////////////////
From demian, 2011/08/30:
...
Sometimes when changing a display mode (like filter or subsample or something) the output of a different filter is returned from the GetPolyData. We used this to optimize some tract visualizations. I tried to use something like a vtk filter that does nothing but being a proxy for doing this but actually this functionality, that you have removed, here makes it more clear that if someone decides to change what GetPolyData returns (changing the pointer), and set the corresponding event, the infrastructure will notice. If you remove the event and the fact that the pointer is not updated is not VERY well documented, the way the pipeline works will become even more obscure.

Up to now, it was the responsibility of the receiving node to decide that if the polydata is the same, it should do nothing. I think this is much more transparent. The way the pipeline and the events work in slicer are already obscure and not documented enough. Which makes it very hard for newcomers to code into it.
...

///////////////////////////////////////////////////////////////////
From finetjul, 2011/08/30:
First of all, you're right, my change will break the current behavior. AsI didn't think the polydata output of a displayable node could change. My bad. I also agree that using a proxy filter is not very elegant (nor any faster).

What I was getting confused with, is that the input of the model node was modified (ModifiedEvent on the input polydata), so the pipeline (input of displayable node) was modified.
It appears that it's not exactly that. It's more that when the internal pipeline of the model node is modified, then we should set the input of the displayable nodes.
Shouldn't we then listen to vtkMRMLDisplayableNode::PolyDataModifiedEvent instead ?
That way part 2 of UpdateSubsampling() would be redundant because being done automatically by ProcessMRMLEvents ?

As a suggestion, I recently cleanup the API of VolumeDisplayNodes:
vtkMRMLVolumeDisplayNode::Get/SetInputImageData
vtkMRMLVolumeDisplayNode::GetOutputImageData
(optinally vtkMRMLVolumeDisplayNode::SetBackgroundImageData() for a 2nd input)
vtkMRMLVolumeDisplayNode::GetScalarImageData() // the first scalar image in the pipeline to compute window/level/threshold

What do you think of :
vtkMRMLDisplayableNode::GetInputPolyData() (or GetSourcePolyData()?)
vtkMRMLDisplayableNode::SetInputPolyData() (or SetSourcePolyData()? or SetAndObserveInputPolyData() )
vtkMRMLDisplayableNode::GetOutputPolyData()

///////////////////////////////////////////////////////////////////
// From demian, 2011/08/30:
My main concern is that, to the best of my knowledge, there is no draft or small doc where the viz pipeline/event system is documented. So it is hard to know where to put stuff and which are the proper events to trigger in order to get the minimal processing possible. Then there is no general consensus about how something should work (which leads to this discussion) and what should/shouldn't be done in each method is also obscure. Maybe I'm wrong but I think that this is one of the reasons why the DT/FiberBunlde pipelines were so redundant and slow.

...
Sounds reasonable but it will be great to have a list of available events used in the pipeline and their semantics somewhere (if it is not there and I have not been able to find it).
...
I think that we have other priorities than go into a major refactoring changing this very frequently used methods' names at this point (before the RSNA deadline). And this could be a great discussion for after the deadline or during the programming week.