Change Details

The rendering mode is ultimately a property of `mitk::BaseRenderer`, that affects its encapsulated `vtkRenderer`. A `vtkRenderer` is added to a `vtkRenderWindow` and a `vtkRenderWindow` can manage //n// `vtkRenderers`. In the workbench scenario, a `mitk::BaseRenderer` is deeply nested in a window/widget/class hierarchy and composition like {nav QmitkAbstractMultiWidget > QmitkStdMultiWidget > QmitkRenderWindowWidget > QmitkRenderWindow > mitk::RenderWindow > mitk::RenderWindowBase > mitk::VtkPropRenderer}. All or most of these classes take a rendering mode parameter in their constructors to pass them down to the nested class(es). The idea is that a rendering mode can be specifically set for a single renderer, but can also being easily set by an accompanied render window and at higher level even by composite multi render window widgets for all containing renderers at once. There are some flaws to this approach as well as old and new bugs. A new bug is that the `QmitkAbstractMultiWidget`-deriving classes do not pass the rendering mode down to their render window widgets. They do store a value copy of the rendering mode, even though it is not a property of themselves. We are treating the rendering mode as a global property by making it accessible in the preferences to set it for each and every renderer at once. This is a valid simplification as mixed rendering modes is usually something to avoid. I think the preferences service is used on multiple levels in the hierarchy described above, though, overriding rendering modes in surprising ways. What was meant as a convenience parameter in all the hierarchy above turned out to be a complexity and synchronization nightmare. I therefore want to remove the rendering mode parameter from basically everywhere, including the currently owning `mitk::BaseRenderer` class, and move it to the central singleton `mitk::RenderingManager` to be handled as a global property as we're doing it anyway. The preference can use the public interface of this class to set/update the rendering mode for all renderers. While investigating rendering mode issues I also noticed that a rendering manager pointer is also passed to nearly every single class ion the hierarchy above. I think, this parameter can also be removed from all of this classes as they can access the single instance nevertheless through its static interface.

The rendering mode is ultimately a property of `mitk::BaseRenderer`, that affects its encapsulated `vtkRenderer`. A `vtkRenderer` is added to a `vtkRenderWindow` and a `vtkRenderWindow` can manage //n// `vtkRenderers`. In the workbench scenario, a `mitk::BaseRenderer` is deeply nested in a window/widget/class hierarchy and composition like {nav QmitkAbstractMultiWidget > QmitkStdMultiWidget > QmitkRenderWindowWidget > QmitkRenderWindow > mitk::RenderWindow > mitk::RenderWindowBase > mitk::VtkPropRenderer}. All or most of these classes take a rendering mode parameter in their constructors to pass them down to the nested class(es). The idea is that a rendering mode can be specifically set for a single renderer, but can also being easily set by an accompanied render window and at higher level even by composite multi render window widgets for all containing renderers at once. There are some flaws to this approach as well as old and new bugs. A new bug is that the `QmitkAbstractMultiWidget`-deriving classes do not pass the rendering mode down to their render window widgets. They do store a value copy of the rendering mode, even though it is not a property of themselves. We are treating the rendering mode as a global property by making it accessible in the preferences to set it for each and every renderer at once. This is a valid simplification as mixed rendering modes is usually something to avoid. I think the preferences service is used on multiple levels in the hierarchy described above, though, overriding rendering modes in surprising ways. What was meant as a convenience parameter in all the hierarchy above turned out to be a complexity and synchronization nightmare. I therefore want to remove the rendering mode parameter from basically everywhere, including the currently owning `mitk::BaseRenderer` class, and move it to the central singleton `mitk::RenderingManager` to be handled as a global property as we're doing it anyway. The preference can use the public interface of this class to set/update the rendering mode for all renderers. While investigating rendering mode issues I noticed that a rendering manager pointer is also passed to nearly every single class in the hierarchy above. I think, this parameter can be removed from all of these classes as they can access the single instance nevertheless through its static interface.

The rendering mode is ultimately a property of `mitk::BaseRenderer`, that affects its encapsulated `vtkRenderer`. A `vtkRenderer` is added to a `vtkRenderWindow` and a `vtkRenderWindow` can manage //n// `vtkRenderers`. In the workbench scenario, a `mitk::BaseRenderer` is deeply nested in a window/widget/class hierarchy and composition like {nav QmitkAbstractMultiWidget > QmitkStdMultiWidget > QmitkRenderWindowWidget > QmitkRenderWindow > mitk::RenderWindow > mitk::RenderWindowBase > mitk::VtkPropRenderer}. All or most of these classes take a rendering mode parameter in their constructors to pass them down to the nested class(es). The idea is that a rendering mode can be specifically set for a single renderer, but can also being easily set by an accompanied render window and at higher level even by composite multi render window widgets for all containing renderers at once. There are some flaws to this approach as well as old and new bugs. A new bug is that the `QmitkAbstractMultiWidget`-deriving classes do not pass the rendering mode down to their render window widgets. They do store a value copy of the rendering mode, even though it is not a property of themselves. We are treating the rendering mode as a global property by making it accessible in the preferences to set it for each and every renderer at once. This is a valid simplification as mixed rendering modes is usually something to avoid. I think the preferences service is used on multiple levels in the hierarchy described above, though, overriding rendering modes in surprising ways. What was meant as a convenience parameter in all the hierarchy above turned out to be a complexity and synchronization nightmare. I therefore want to remove the rendering mode parameter from basically everywhere, including the currently owning `mitk::BaseRenderer` class, and move it to the central singleton `mitk::RenderingManager` to be handled as a global property as we're doing it anyway. The preference can use the public interface of this class to set/update the rendering mode for all renderers. While investigating rendering mode issues I also noticed that a rendering manager pointer is also passed to nearly every single class ion the hierarchy above. I think, this parameter can also be removed from all of thisthese classes as they can access the single instance nevertheless through its static interface.