# VTK 9.0.2
**URL:** https://discourse.vtk.org/t/vtk-9-0-2/6107
**Category:** Announcements
**Tags:** release-process
**Created:** [June 30, 2021, 2:45pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107 "2021-06-30T14:45:18Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [June 30, 2021, 2:45pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/1 "2021-06-30T14:45:18Z")
It’s finally here 🙂 .
Wheels have been uploaded to PyPI and [VTK’s package registry](https://gitlab.kitware.com/vtk/vtk/-/packages/17). Source, data, and documentation tarballs are on the website.
Still TODO:
- ~~upload 9.0.2 Doxygen to the website~~ Seems VTK has never hosted versioned documentation
- update [Download | VTK](http://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)
---
### Author:  [@larsoner](https://discourse.vtk.org/u/larsoner)
#### Post date: [June 30, 2021, 5:07pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/2 "2021-06-30T17:07:26Z")
Was debugging leaks intentionally left enabled? I get this now on the Linux 9.0.2 wheels:
```auto
$ python -c "import vtk"
vtkDebugLeaks has found no leaks
$
```
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [June 30, 2021, 5:17pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/3 "2021-06-30T17:17:25Z")
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 🙂 .
---
### Author:  [@will.schroeder](https://discourse.vtk.org/u/will.schroeder)
#### Post date: [June 30, 2021, 5:21pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/4 "2021-06-30T17:21:20Z")
Ben, please enlighten me: are these wheels being built release, and is TBB or any non-serial SMP enabled ?
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [June 30, 2021, 5:28pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/5 "2021-06-30T17:28:51Z")
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.
---
### Author:  [@Andrew](https://discourse.vtk.org/u/Andrew)
#### Post date: [July 1, 2021, 7:12am UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/6 "2021-07-01T07:12:36Z")
Would love fix [https://gitlab.kitware.com/vtk/vtk/-/commit/6c26ec47576c3e6126c650ed355dba51198c2719](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.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [July 1, 2021, 11:14am UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/7 "2021-07-01T11:14:44Z")
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](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8134)
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [July 1, 2021, 12:22pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/8 "2021-07-01T12:22:42Z")
@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_.
---
### Author:  [@larsoner](https://discourse.vtk.org/u/larsoner)
#### Post date: [July 1, 2021, 12:34pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/9 "2021-07-01T12:34:18Z")
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](https://gitlab.kitware.com/vtk/vtk/-/issues/18242#note_973845)
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [July 1, 2021, 12:41pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/10 "2021-07-01T12:41:30Z")
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.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [July 1, 2021, 1:11pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/11 "2021-07-01T13:11:24Z")
Backport is reverted here: [https://gitlab.kitware.com/vtk/vtk/-/merge\_requests/8136](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8136)
---
### Author:  [@akaszynski](https://discourse.vtk.org/u/akaszynski)
#### Post date: [July 1, 2021, 4:48pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/12 "2021-07-01T16:48:10Z")
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…
---
### Author:  [@akaszynski](https://discourse.vtk.org/u/akaszynski)
#### Post date: [July 1, 2021, 4:49pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/13 "2021-07-01T16:49:19Z")
I recommend 9.0.2 be yanked, the dev wheels don’t have this issue…
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [July 1, 2021, 5:17pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/14 "2021-07-01T17:17:35Z")
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.
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [July 1, 2021, 5:30pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/15 "2021-07-01T17:30:30Z")
> [@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**
>
> ```python
> #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.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [July 1, 2021, 5:55pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/16 "2021-07-01T17:55:54Z")
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.
---
### Author:  [@akaszynski](https://discourse.vtk.org/u/akaszynski)
#### Post date: [July 1, 2021, 6:11pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/17 "2021-07-01T18:11:44Z")
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](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7095)
See discussion here:
[https://gitlab.kitware.com/vtk/vtk/-/issues/17917](https://gitlab.kitware.com/vtk/vtk/-/issues/17917)
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [July 1, 2021, 6:14pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/18 "2021-07-01T18:14:52Z")
> [@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?
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [July 1, 2021, 6:52pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/19 "2021-07-01T18:52:41Z")
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.
---
### Author:  [@will.schroeder](https://discourse.vtk.org/u/will.schroeder)
#### Post date: [July 1, 2021, 6:52pm UTC](https://discourse.vtk.org/t/vtk-9-0-2/6107/20 "2021-07-01T18:52:45Z")
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](mailto:ben.boeckel@kitware.com) or [@Timothée Couble](mailto:timothee.couble@kitware.com) have more to say on this matter.
[Next page](https://discourse.vtk.org/t/vtk-9-0-2/6107.md?page=2)