Vispy 0.12: per-point symbol and several bugfixes

[brisvag]

Description

Bump vispy to 0.12. This fixes several bugs that we fixed upstream, and introduces some new functionality. In short:

• symbol is now per-point, just like size, color and and so on. I added a small example to showcase this:

multi_symbol.mp4

• fixes Inconsist size of Point when rotate in 3d #2213, a long-standing issue with anisotropic scaling and points. To fix this, we now set the size of points correctly in world space, which is different from what currently happens in napari. On main, points with size 10 and scaling 2 will result in actual size of 20. While this may seem reasonable in some cases, it breaks down with anisotropic scales. With this fix, a size of 10 will be 10 no matter the scaling. This means that this might "break" some existing code which relied on the bug.

• fixes the issue with clipping planes slowing down points reported in Dimension slider is very slow with points layer #5123, which was patched with an ugly workaround in Fix slow points #5133. The workaround is no longer needed.

• thanks to @aganders3, the attenuated_mip portion of Volume rendering updates for isosurface and attenuated MIP #5215 was upstreamed to vispy, so it's no longer needed here

• thanks to @psobolewskiPhD , more PySide6 complications were fixed :)

• gpu image interpolation with custom kernels was fixed, which allows to move forward with expose custom image interpolation kernels #5130

• bonus: instanced rendering is now a first-class citizen in vispy, so we can start experimenting how to use it in napari :P

Type of change

• Bug-fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

[brisvag]

Turns out there was a bug in vispy 0.12. Will push 0.12.1 soon with a fix.

[codecov]

Codecov Report

Merging #5312 (ccae493) into main (58c0ca8) will increase coverage by 0.00%.
The diff coverage is 95.65%.

❗ Current head ccae493 differs from pull request most recent head 52804a1. Consider uploading reports for the commit 52804a1 to get more accurate results

@@           Coverage Diff           @@
##             main    #5312   +/-   ##
=======================================
  Coverage   89.01%   89.02%           
=======================================
  Files         594      594           
  Lines       50237    50277   +40     
=======================================
+ Hits        44719    44758   +39     
- Misses       5518     5519    +1     

Impacted Files	Coverage Δ
napari/_vispy/visuals/points.py	100.00% <ø> (ø)
napari/_vispy/visuals/volume.py	100.00% <ø> (ø)
napari/layers/image/image.py	95.30% <66.66%> (-0.44%)	⬇️
napari/_qt/layer_controls/qt_points_controls.py	92.05% <90.90%> (+0.10%)	⬆️
napari/layers/points/points.py	98.83% <94.59%> (-0.24%)	⬇️
napari/_qt/_tests/test_qt_viewer.py	94.45% <100.00%> (+0.02%)	⬆️
...i/_qt/layer_controls/_tests/test_qt_image_layer.py	100.00% <100.00%> (ø)
napari/_tests/test_mouse_bindings.py	94.07% <100.00%> (+0.16%)	⬆️
napari/_tests/test_notebook_display.py	100.00% <100.00%> (ø)
napari/_tests/test_viewer.py	96.37% <100.00%> (+0.01%)	⬆️
... and 17 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[brisvag]

Yes; check this ci run for an example failure. Unfortuantley, I don't know how to get more info than this :/

[andy-sweet]

Yes; check this ci run for an example failure. Unfortuantley, I don't know how to get more info than this :/

I don't a see a segfault there - instead an InvocationError from tox? I'm going to create a py38 env on my windows machine then run all the tests through tox to see if I can reproduce.

[andy-sweet]

I don't a see a segfault there - instead an InvocationError from tox?

Ah, I guess tox is running pytest in another subprocess and that process is ending with a segfault? The exit code in the CI logs is 3221225477, which I don't understand, even with the docs from tox.

I'm going to create a py38 env on my windows machine then run all the tests through tox to see if I can reproduce.

I have some issues getting tox to work in my py38 environment. But the tests skipped here work with direct calls to pytest in such an environment, so that's more good news :)

Still not particularly happy about skipping tests without well understood reasons, but it's not enough to block this PR, which we should get in soon to start exercising vispy 0.12.

[Czaki]

3221225477

this looks like a memory violatation error based on fast google.

[brisvag]

I don't a see a segfault there - instead an InvocationError from tox?

Right, my bad: unfortunately when you run tox with -v, somehow you lose some of these deep tracebacks. Here's a failure where you can see some more details about the errors. It's indeed an access violation, and googling around that error code did not really bring me anywhere.

Still not particularly happy about skipping tests without well understood reasons

Yeah I feel the same, but if the tests block us completely rather than finding real errors, they're counterproductive.

[andy-sweet]

Yeah I feel the same, but if the tests block us completely rather than finding real errors, they're counterproductive.

Like I said, I don't think this PR is blocked, so you should feel free to merge. I may dig a little deeper and follow up with some findings later though, as the error is pretty clearly related to the new vispy version (though it's still unclear if it's only Windows CI where that can happen).