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