Noteworthy as it containes BREAKING CHANGES for some ModelFit dependent modules and plugins.

I think I found a nice solution. Depth peeling is set per renderer, not for the whole application. So it makes sense to activate it only for 3d renders. Side effect: probably speeds up rendering a little bit.

In T23741#203910, @kalali wrote:

Can T14333: Improve mitk::UIDGenerator be closed?

It's depth peeling and it is not solved with VTK 9. I tried to narrow down the issue in a minimum VTK application but I wasn't able to reproduce it. As quite a significant amount of time already was spent here, I will probably reintroduce preferences to disable/enable depth peeling and declare this issue as a known issue.

Can T14333: Improve mitk::UIDGenerator be closed?

For mitk::UIDGenerator I have decided to base it internally on boost::uuid (name_generator).

I have now removed the dysfunctional Clone for now. See D303

Discussion results: check in our code base of someone uses the method. If not: Just remove it. If Yes: Look how they used/need it.

Pushed new branch T22616-Store_version_and_reader_information.

The follwing informations are stored now in properties.

This branch contains a interface breaking commit for all classes
derived from AbstractFileReader. Derived classes have to
implement now "std::vector<BaseData::Pointer> DoRead()".
Normaly the only thing to do, is to rename the Read()
implementation of the derived class to DoRead().

Feature classes where reworked, and cleaned up. Introduce FeatureID allow for more export flexibility but API of feature classes have some breaking changes.

Pushed new branch T25466-Compact_TemporoSpatialStringProperty_serialization.

This task will focuse on the ability to condense the TemperoSpatialStringProperty, if possible when it is serialzed by serializeTemporoSpatialStringPropertyToJSON().
As this is the most important aspect of the task to ensure compact storing of properties into files.

We should inform about the change and tell them that the can drag whole directories if the want to still read the whole DICOM content of a dir at once.

Pushed new branch T27321-Improve_DICOM_3DnT_handling.

Pushed new branch T27317-Cmdapp_for_3D+t_fusion.

This also might have impact on T27065 and T25702

Pushed new branch T27038-ExtensionProjects.

In T26980#193572, @floca wrote:

@kislinsk You mentioned that we should do something as soon as the (wrong) autload dependencies are gone. I cannot remember what, do you? May be some work arround in our packaging code due to the autoload modules?

@kislinsk You mentioned that we should do something as soon as the (wrong) autload dependencies are gone. I cannot remember what, do you? May be some work arround in our packaging code due to the autoload modules?

Pushed new branch T27041-MITK_CUSTOM_REVISION_DESC.

I have introduced a new superbuild and MITK-build advanced cache variable called MITK_XVFB_TESTING. If switched on, it will prepend testdriver calls with xvfb-run --auto-servernum resulting in having a virtual frame buffer available for rendering tests. This is useful in headless systems like continuous integration clients. Works for Linux. To install xvfb call sudo apt install xvfb.

In Visual Studio, all MITK targets are now categorized in folders. MITK extension targets have their own root folder.

Pushed new branch T26954-UseFolders.

Pushed new branch T26936-MigrateUiStdMultiWidgetNames.

Pushed new branch T26936-FixStdMultiWidgetRenderWindowNames.

Pushed new branch T26795-Fix-gcc.

Pushed new branch T26815-Fixes.

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.

• 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 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).