VTK 9.0.2

[ben.boeckel (Ben Boeckel (Kitware))]

It’s finally here .

Wheels have been uploaded to PyPI and VTK’s package registry. Source, data, and documentation tarballs are on the website.

Still TODO:

• [x] upload 9.0.2 Doxygen to the website Seems VTK has never hosted versioned documentation
• [x] update vtk.org/download with the new release

Future releases will have CI assist more in doing a lot of the manual steps.

Release notes:

VTK 9.0.2 collects fixes to 9.0.1 which have been made since its release. Of
particular interest are the fixes to macOS rendering, support for the macOS
arm64 platform, and updates for API changes in external libraries.

New classes

• Added a vtkImageProbeFilter which works like vtkProbeFilter, but for vtkImageData

New support

• enum class setters and getters are now supported via vtk{Get,Set}EnumMacro

Fixes

• The QVTKRenderWidget.h is now installed.
• vtk3DLinearGridPlaneCutter guards against nullptr points and cells
• The composite date mapper now iterates over data blocks properly
• vtkStringArray::Resize takes tuple elements into account
• vtkArrowSource now supports scalong and rotation around the origin or the arrow’s center point
• The VTK::DomainsChemistryOpenGL2, VTK::RenderingContextOpenGL2, and VTK::RenderingOpenGL2 modules are added to the Rendering group to avoid missing implementations of rendering components
• vtkCutter enables point merging when requested through a vtkPointLocator which merges points
• vtkAxesActor bounds calculations improved to avoid assumptions about range values
• vtkWindowLevelLookupTable out-of-range colors are now initialized properly
• vtkImageReslice::RequestInformation is refactored handle common image information passing
• vtkImageReslice creates a new interpolator in ::GetInterpolator; this new interpolator now uses the same interpolation mode as vtkImageReslice itself

macOS

• macOS wheels are now built and uploaded by VTK’s CI
• Fixes for macOS OpenGL state tracking (related to GL_SCISSOR)
• Multisampling on macOS with Intel graphics turned off for volume rendering
• OpenGL state tracking on macOS with layers is improved (rather than using the wrong context between layers)
• OSPRay is disabled when running under macOS Rosetta

Third Party

• HDF5 has been updated to address errors on newer Xcode compilers
• HDF5 macOS universal2 compilation fixes
• VTK::mpi now disables C++ bindings for SGI MPT as well
• Usage of numpy.character is removed (deprecated in NumPy 1.19)
• Avoidance of APIs deprecated in Python 3.9
• Compilation with newer libfreetype resolved (FT_CALLBACK_DEF usage removed)

[larsoner (Eric Larson)]

Was debugging leaks intentionally left enabled? I get this now on the Linux 9.0.2 wheels:

$ python -c "import vtk" 
vtkDebugLeaks has found no leaks
$

[ben.boeckel (Ben Boeckel (Kitware))]

Thanks for testing. Our CI does that for all builds; I didn’t consider its effects on the wheels. I’ll disable it for them. I guess there will be a 9.0.3 .

[will.schroeder]

Ben, please enlighten me: are these wheels being built release, and is TBB or any non-serial SMP enabled ?

[ben.boeckel (Ben Boeckel (Kitware))]

The wheels are built in Release mode, but have no external dependencies enabled (because there’s no mechanism to ensure we don’t conflict with other wheels attempting the same thing). They all use just Sequential at the moment; STDThread didn’t exist before and OpenMP has been largely untested.

[Andrew (Andrew Wilson)]

Would love fix https://gitlab.kitware.com/vtk/vtk/-/commit/6c26ec47576c3e6126c650ed355dba51198c2719 to be included in 9.0.3 or next release if possible. We maintain our own fixed version of vtkXRenderWindowInteractor for it currently.

[ben.boeckel (Ben Boeckel (Kitware))]

I’ve added that commit’s MR to the 9.0.3 milestone so it will be picked up by the backporting script. https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8134

[ben.boeckel (Ben Boeckel (Kitware))]

@Andrew @ken-martin Could you give me a release note blurb about that change…I can’t say I know what it’s actually fixing and the commit message is fairly mechanical and unhelpful in such regards as to its effects.

[larsoner (Eric Larson)]

Also when considering the backport, keep in mind that commit seems to create stability issues:

https://gitlab.kitware.com/vtk/vtk/-/issues/18242#note_973845

[ben.boeckel (Ben Boeckel (Kitware))]

Hrm, well, that simplifies the release note thing…if that’s the case, I’m of a mind to keep it out of 9.0.3 then.

[ben.boeckel (Ben Boeckel (Kitware))]

Backport is reverted here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8136

[akaszynski (Alex Kaszynski)]

Also, plotting windows are suddenly not closing again on Linux. Issue doesn’t occur on 9.0.20210612.dev0 vtk wheels. I’m wary of doing another bisect…

[akaszynski (Alex Kaszynski)]

I recommend 9.0.2 be yanked, the dev wheels don’t have this issue…

[ben.boeckel (Ben Boeckel (Kitware))]

The dev wheels are very far away from 9.0.2, so that would need investigation into what on master fixed it. Does 9.0.1 have the same issue? If so, it’s not something that is newly broken in 9.0.2.

[lassoan (Andras Lasso)]

@ben.boeckel

The wheels are built in Release mode, but have no external dependencies enabled (because there’s no mechanism to ensure we don’t conflict with other wheels attempting the same thing). They all use just Sequential at the moment; STDThread didn’t exist before and OpenMP has been largely untested.

We need a better answer for this. Modern VTK filters perform really badly with Sequential backend. Just one example. I’ve run vtkWindowedSincPolyDataFilter with the exact same script on the same data set in 3D Slicer and the new VTK-9.0.2 release:

• VTK in 3D Slicer’s Python environment (using TBB SMP backend): 0.56 seconds
• VTK-9.0.2 Python package: 8.9 seconds

Test code

#vtk speed
import time, vtk

reader = vtk.vtkSTLReader()
reader.SetFileName(r"c:\Users\andra\tmp\Segment_1.stl")
reader.Update()
startTime = time.time()
smoothing = vtk.vtkWindowedSincPolyDataFilter()
smoothing.SetInputData(reader.GetOutput())
smoothing.Update()
print(f"Smoothing completed in {time.time() - startTime} seconds.")

VTK Python packages should be probably built with TBB backend, the same way as Numpy, SciPy, and scikit-learn.

[ben.boeckel (Ben Boeckel (Kitware))]

Once master has a release cut, the STDThread backend will be available. There’s no much I’m going to be able to do with 9.0.3 on that front. Shipping TBB this late in the release cycle isn’t something I have time or motivation to do.

[akaszynski (Alex Kaszynski)]

This makes sense now. Thought 9.0.2 was direct from master.

Render window closing issue was resolved with:
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7095

See discussion here:
https://gitlab.kitware.com/vtk/vtk/-/issues/17917

[lassoan (Andras Lasso)]

@ben.boeckel

Once master has a release cut, the STDThread backend will be available.

@will.schroeder is STDThread backend expected to have performance similar to TBB?

[ben.boeckel (Ben Boeckel (Kitware))]

I looked at that MR and it’s too big for a patch release like this. I also noticed that it is using select when some other mechanism should be preferred (probably poll to maintain compatibility) due to the "fd value is too large for select to support" problem.

[will.schroeder]

At this point I don’t know how STDThread and TBB will compare. I am concerned that STDThread, at least in the short term, will not leverage thread pools. This could have a very large negative impact, but until I have time to try it out I am withholding judgement. I have heard rumblings of future thread pool support in C++, but nothing definitive. Maybe @Ben Boeckel or @Timothée Couble have more to say on this matter.