Difference between revisions of "Documentation/Labs/VTK8"
Max.smolens (talk | contribs) (→Tests) |
Max.smolens (talk | contribs) (→Status) |
||
| Line 8: | Line 8: | ||
* Builds on Linux and Windows; Mac is untested. Test runs are in progress. | * Builds on Linux and Windows; Mac is untested. Test runs are in progress. | ||
| − | * | + | * Windows shows OpenGL errors at exit with the OpenGL backend. The OpenGL2 backend is untested. |
| + | <pre> | ||
| + | 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 | ||
| + | </pre> | ||
* "VTKv7" project name needs to be updated to "VTKv8". | * "VTKv7" project name needs to be updated to "VTKv8". | ||
* <del>EMSegment remote module will require updates to fix vtkDebugLeaks output.</del> (updated in r17131) | * <del>EMSegment remote module will require updates to fix vtkDebugLeaks output.</del> (updated in r17131) | ||
Revision as of 20:08, 29 June 2017
Home < Documentation < Labs < VTK8This page documents the update of Slicer to use VTK 8.0.
Contents
Overview
It is planned to update the version of VTK that Slicer uses from 7.1 to 8.0.
Status
- Builds on Linux and Windows; Mac is untested. Test runs are in progress.
- Windows shows OpenGL errors at exit with the OpenGL backend. The OpenGL2 backend is untested.
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
- "VTKv7" project name needs to be updated to "VTKv8".
EMSegment remote module will require updates to fix vtkDebugLeaks output.(updated in r17131)
Branches/Merge Requests
VTK:
Slicer:
Outstanding VTK issues
- Should upstream fix to respect access specifier of using statements in wrapping
Slicer-specific VTK commits
Slicer's VTK 8.0 branch includes fixes/changes that aren't in upstream:
- Respect access specifier of using statements in wrapping
- ENH: Allow selection of seed points using vtkSeedWidget
- Ensure vtkVariant stream associated with << operator is set back to "dec".
- BUG: WIP: fix vtkPickingManager interaction with widgets
Tests
This section lists test failures on each platform for Release builds.
Windows:
Test results:
- TBD
Linux:
Test results:
- http://slicer.cdash.org/viewTest.php?onlyfailed&buildid=1052932 (Release configuration, OpenGL backend, Ubuntu 16.04)
- py_nomainwindow_SlicerOptionDisableSettingsTest passed when re-run.
- py_StandaloneEditorWidgetTest is vtkDebugLeaks; perhaps unrelated to this change.
OS X:
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. Using the OpenGL2 backend in Slicer is untested and may require updates to properly build and function. This rendering backend in Slicer is set using Slicer_VTK_RENDERING_BACKEND.
OpenGL2 backend known issues
Open
- Need to move OS X nightly build to new factory machine to be able to set CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.7. This will ensure that the required OpenGL version is found. See https://github.com/Slicer/Slicer/pull/595.
- 4252: Slicer crashes on start when started through Windows Remote Desktop
Discussion
The transition plan was announced on the Slicer forum: https://discourse.slicer.org/t/transition-to-vtk-8-0/379.
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 https://github.com/Slicer/Slicer/blob/master/CMake/vtkMacroKitPythonWrap.cmake.
References:
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.
References:
- https://github.com/Kitware/VTK/commit/e5c793dbdf87e838bb2b60c6a5905ced0e5548f9
- http://public.kitware.com/pipermail/vtk-developers/2016-September/034332.html
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.
