Pushed new branch T26752-Boost-RPATH-2.

Pushed new branch T26815-Fixes.

Fix in https://github.com/MITK/MITK/pull/245, patches VTK

This has been closed years ago - not sure why it has been reopened.

In T26653#188477, @kislinsk wrote:

@maleike

I re-enabled depth peeling support based on your pull request and also enabled depth peeling for volumes and FXAA. It works well for surfaces and volumes but totally breaks rendering of images/cross hair with opacity < 1. So this is not yet complete and I/we have to fix this before I am able to merge it.

Pushed new branch T26167-ExtractSliceFilter_fix_generateoutputinformation.

• Remove any mitk::RenderingManager and mitk::BaseRenderer::RenderingMode::Type parameters from function calls that generate corresponding compiler errors
• Unify access to the rendering manager by always using the static method mitk::RenderingManager::GetInstance()

Pushed new branch T26815-RemovePassingOfRenderingManagerAsParameter.

I started reviewing the plugin.
Things I found will be directly mentioned in comments in your commits.

I see your point. I don't see a difference compared to the current situation neither.
I'm not specifically talking about performance issues here but rather envision a scenario where an StdMultiWidget (or any other AbstractMultiWidget) is used to display medical image for interaction purposes and another single render window, e.g. inside a DICOM preview plugin or similar, shows another medical image, e.g. and you don't want this to be reinitialized or zoomed or moved simultaneously with the interaction inside the StdMultiWidget.
This is just something to consider in the future and I also see the point in the caller vs callee issue. The new multi widget still struggles with all the RequestUpdateAll calls and similar so that it is not easy to use the new multi widget the correct way (see T26496).

Thanks for the comments. The rendering manager is already designed to be a singleton and only a singleton. There's flexibilty in terms of a rendering manager factory that is used to determine the actual implementation of a rendering manager (like the QmitkRenderingManager) but still a singleton one. So I think we would not loose anything with the new approach compared to the current situation. I even think that the rendering manager should stay a singleton in the future as it is kind of a bridge to VTK and at the end of the day to the single OpenGL context of the application despite all the possible renderers (sharing that context). Calling RequestUpdateAll() all over the place is a caller issue anyway in my opinion and not a callee issue. If this should ever be a relevant performance issue with multiple editors, we could check if we really need to update specific render windows based on their visibility, if we (or even VTK) are not already doing this.

And you are right, the QmitkAbstracMultiWidget receives a rendering mode but each subclass (e.g. the QmitkStdMultiWidget) does not access and use it to create its QmitkRenderWindowWidget (however, here the rendering mode is passed to the QmitkRenderWindow).

Should be fixed now. Different multi widgets use different action event handler.

One point I want to mention here, before I dive deeper into the problem is that we cannot use multiple rendering manager, if we rely on each class accessing the singleton rendering manager. So far this was probably never a problem but we should consider this in the future.
Having a single rendering manager means having all existing render windows available in that rendering manager and thus always updating them all e.g. on request update all.
We are not able to distinguish e.g. between the render windows of the std multi widget and another render window (e.g. a small preview render window inside a plugin view).

Pushed new branch T26811-RenderingModePreference.

This fixes the problem but another problem arises, which is due to the use of the DisplayActionEventFunctions and the implementation inside QmitkAbstractMultiWidget:
A widget can either have a synchronized or a de-synchronized interaction. However, in the case of the StdMultiWidget all interactions are de-synchronized, except for the SetCrosshair-action. So in the StdMultiWidget-case we have to handle the action events differently.

Pushed new branch T26795-Disable-simultaneous-scrolling.

Pushed new branch T26653-MasterIntegrationFixes.

All remaining issues solved by @maleike. I reintroduced the rendering mode preference but instead of switching between "Standard" (default, basically equivalent to "nothing") and "Depth Peeling" it now allows to switch between "No anti-aliasing" and "Fast Approximate Anti-Aliasing (FXAA)" (default). Depth peeling is always enabled as it only kicks in if there are translucent objects in the scene and in the worst case it is preferable to have not the fasted rendering instead of having a broken rendering. The future will show if we there is really a need to additionally add quality options regarding depth peeling.

I remember having seen this error but I thought I fixed it. Currently, I cannot reproduce it, using the latest master 8a6a7a85.
Could you give a precise description of the steps to take in order to reproduce this bug?