Update: Toward Slicer 4.10.0

release status

We are getting close ! Thanks you everyone :+1:

But considering that:

  • the last VTK update addressing the #4510 (Cropping is broken with GPU Volume rendering if depth peeling is enabled), also introduced a regression.

  • there are still issues with the extension build system. - will be addressed in 4.10.0

  • issue #4511 (Large camera view angle (used in OpenVR) not properly handled with GPU Volume Rendering) is not yet resolved. That seriously limits the usability of the SlicerVirtualReality extension.

  • Pre-built and Locally-built 3dSlicer under Ubuntu 16.04 do NOT start - will be addressed in 4.10.0

  • #4530 Slice viewer are too small after switching to conventional layout

  • #4517 macOS: Slicer dmg installer and Slicer app do not have the icon. Now fixed in r27123

  • and few other ones,

I suggest we delay the release by few days/s>.

That should enable us to address the most critical issues and transition into their own extension: BRAINSTools, EMSegment, and SimpleITK. And ExpertAutomatedRegistration module into the existing LegacyModules extension.

infrastructure updates

The past few days were spent updating the CI and build infrastructure so that we have Linux build done with Qt5. And here it is:


Since our server metroplex doesn’t have a host operating system suitable to generate distributable packages, it is using the build environment slicer/buildenv-qt5-centos7 (itself built on top of the dockbuild/centos7-devtoolset4-gcc5 dockbuild image)

Here is the section of the night script responsible for driving the Slicer Preview build and packaging. Note that run_ctest_with_test default to FALSE.


The build itself uses the latest version of CMake (v3.11.0) and a modified version of ninja generator that supports GNU make jobserver. This ensures the child processes spawn within each external projects communicate with the top-level process.

To control the number of overall processes, the CMAKE_JOB_* options are particularly useful. In our case, we configure the compile and the link pool with different values. Considering metroplex has 32 cores and 32GB of memory, the settings are currently the following:


Given the highly templated nature of some of our code (SimpleITK, ITK, vtkITK, …), the link jobs require a lot of memory, for that reason we set a smaller maximum number of link job.

This will also be particularly useful on CircleCi where there is also 32core but only 4GB (by default), we will be able to leverage the number of core while drastically limiting the number of parallel link job.


Thanks for pulling this together Jc!

I’d add this slice rendering performance issue to the short list of issues that we should resolve before the release: https://issues.slicer.org/view.php?id=4496

Reslicing is a core function and I think people will be disappointed if we have a release with a major regression.

@lassoan have you done any further testing or debugging on this?

Yes, and I have a solution that makes slice browsing very fast (60-90fps now, instead of 10fps) on fast computers, with NVidia GPUs. I have some other attempts to improve performance, but those don’t seem to make much difference. See details here: https://github.com/Slicer/Slicer/pull/930.

Out of curiosity, are there any new updates about when the next Slicer version is expected for release? I saw this post is about 12 weeks old and couldn’t find any new information indicating a new timeline for release.

There are still 19 open issues for 4.9 that must be addressed. My estimation would be a few more weeks.

1 Like

To follow up, all Slicer 4.9 issues have been addressed: https://issues.slicer.org/view_all_bug_page.php?filter=51308