From Slicer Wiki
Jump to: navigation, search
Home < Documentation < Labs < VTK8

This page documents the update of Slicer to use VTK 8.0.


It is planned to update the version of VTK that Slicer uses from 7.1 to 8.0.


   Generic Warning: In C:\path\to\S\VTKv7\Rendering\OpenGL\vtkOpenGLDisplayListPainter.cxx, line 52
   failed after ReleaseAllLists 16 OpenGL errors detected
   0 : (1282) Invalid operation
   1 : (1282) Invalid operation
   15 : (1282) Invalid operation
  • Likely will need to build Slicer with C++11 support.
  • On Mac, if targeting 10.7 or 10.8, likely will need to set CMAKE_CXX_FLAGS=-stdlib=libc++ for C++11 support. Note that this would require Qt build with libc++, which is officially supported by Qt5. Note: Qt 5.7.1 minimum officially supported deployment target is 10.8.
  • There may be picking issues with widgets. For example, the slice view ROI handles don't work correctly.
  • * Windows (VS2013) may have a dependency issue related to Python wrapping. At first, wrapping seems to not use the hierarchy files or runs before they are available. Building again generates the wrapped classes correctly. (resolved)
  • Update "VTKv7" project name to "VTKv8".
  • Add Slicer_VTK_VERSION_MAJOR option to support building with VTK7 and VTK8, as was done for VTK5/6 in VTK7 wrapping should not build the hierarchy files.
  • EMSegment remote module will require updates to fix vtkDebugLeaks output. (updated in r17131)

Branches/Merge Requests



Outstanding VTK issues

Slicer-specific VTK commits

Slicer's VTK 8.0 branch includes fixes/changes that aren't in upstream:

Test results


Test results:


Test results:


Test results:

  • TBD

Rendering backend

Although VTK 7 changed the default setting of VTK_RENDERING_BACKEND to OpenGL2, Slicer still explicitly sets it to OpenGL. The rendering backend in Slicer is set using Slicer_VTK_RENDERING_BACKEND.

OpenGL2 backend known issues


The transition plan was announced on the Slicer forum:

Migration guide

This section lists categories of code changes necessary to build and run Slicer with VTK 8.0. Each category has a short description, a suggested upgrade path, and references to relevant commits (TBD once merged).

Use hierarchy files for VTK Python wrapping

In VTK8 it's necessary to generate hierarchy files for proper wrapping VTK classes in Python. Without the information provided by the hierarchy files, the Python wrapping tool lacks complete information about classes and types. In this case, the generated classes contain methods that shouldn't be wrapped and fail to compile, and include references to types such as vtkTypeBool. Once the hierarchy files are generated and provided to the Python wrapping tool, the generated classes compile and typedefs like vtkTypeBool are correctly resolved.

Once the VTK8 changes are merged, generating hierarchy files is handled by


Call InitializeObjectBase() in vtkObject New() methods

In VTK8 it's necessary for vtkObject New() methods to call InitializeObjectBase() on the new object for proper tracking with vtkDebugLeaks. The standard macros (vtkStandardNewMacro, vtkObjectFactoryNewMacro) handle this. For those classes that don't use the macros, add a call to InitializeObjectBase() immediately after constructing the object by new vtkXXX().

Additionally, vtkObjectFactory::CreateInstance() now doesn't register the class name with vtkDebugLeaks if the factory fails to create the object. Therefore, it's no longer necessary to unregister the class name with vtkDebugLeaks. Remove calls to vtkDebugLeaks::DestructClass(className) following vtkObjectFactory::CreateInstance().

To support both VTK8 and earlier versions of VTK, wrap these changes in preprocessor checks for whether VTK_HAS_INITIALIZE_OBJECT_BASE is defined.


Future work

Future work in Slicer related to VTK 8 could include:

  • Remove BTX/ETX markers.
  • Check for and resolve build warnings in Slicer VTK classes.
  • Check that settings in External_VTKv8.cmake are all still necessary, specifically VTK_USE_PARALLEL, and anything related to Qt.