Skip to content

Fix for VTK9 on Mac#16

Closed
banesullivan wants to merge 1 commit intomasterfrom
fix/vtk9-mac
Closed

Fix for VTK9 on Mac#16
banesullivan wants to merge 1 commit intomasterfrom
fix/vtk9-mac

Conversation

@banesullivan
Copy link
Copy Markdown
Member

Resolve #15

This works for me locally... someone else should double-check that this is okay (no longer calling initialize at all). Following advice in https://discourse.vtk.org/t/vtk-9-pyqt-macos-no-rendering/3358/14

cc @larsoner and @GuillaumeFavelier

@akaszynski
Copy link
Copy Markdown
Member

Can't test at the moment, but I'll finally be getting a Mac shortly for another project...

@GuillaumeFavelier
Copy link
Copy Markdown
Contributor

I looked at the link and apparently the order is important, Initialize needs to be called after show().

In blockbuilder, I created a showEvent() function that calls Initialize after the event is accepted (not tested on mac).

Another solution would be to create a show_signal connected to the Initialize() of the interactor.

@larsoner
Copy link
Copy Markdown
Contributor

If we can get away with not calling Initialize at all and let VTK figure out the right time to do it (?), then that seems safest. I'll check to see if this fixes things for me on my macOS laptop...

@GuillaumeFavelier
Copy link
Copy Markdown
Contributor

GuillaumeFavelier commented Jun 16, 2020

Quoting David Gobbi: "QVTKRenderWindowInteractor.py does not call Start() or Initialize() itself, there’s nothing that can be done there."

Reference: https://discourse.vtk.org/t/vtk-9-pyqt-macos-no-rendering/3358/22

If it's working for everyone without Initialize(), it's fine by me.

@larsoner
Copy link
Copy Markdown
Contributor

I get a segfault on this branch with the MNE example I usually test with. We could connect to the show signal, but at least at the MNE end this will not fix the problem because we still risk creating a bunch of objects before show actually gets called.

For now (for us at least) it might be best just to not use VTK9 until they release new wheels with the fix / backport they're doing.

@akaszynski
Copy link
Copy Markdown
Member

For now (for us at least) it might be best just to not use VTK9 until they release new wheels with the fix / backport they're doing.

I'm also having trouble with VTK9 on Linux with the render window refusing to close.
https://gitlab.kitware.com/vtk/vtk/-/issues/17917

Might be best to wait for the next set of wheels.

@banesullivan
Copy link
Copy Markdown
Member Author

Might be best to wait for the next set of wheels.

Honestly, I have no idea when that could be though...

@banesullivan
Copy link
Copy Markdown
Member Author

@larsoner and @akaszynski, what if we hardset pyvistaqt to have vtk<'9.0.0' in its setup.py until we can fix these things and/or the next set of wheels come out?

@larsoner
Copy link
Copy Markdown
Contributor

It would be good if platform selectors could be used like in pip (see for example this commit), but I've never tried to do this in setup.py so I'm not sure how feasible it is.

@larsoner
Copy link
Copy Markdown
Contributor

larsoner commented Jun 25, 2020

FYI VTK 9.0.1 is now available on PyPi, but it still renders some garbage for me :(

@akaszynski
Copy link
Copy Markdown
Member

FYI VTK 9.0.1 is now available on PyPi, but it still renders some garbage for me :(

Also still having issues with render windows closing on Linux.

@banesullivan
Copy link
Copy Markdown
Member Author

FYI VTK 9.0.1 is now available on PyPi, but it still renders some garbage for me

VTK 9.0.1 is working all fine for me on mac with BackgroundPlotter. It seems to have fixed all of my issues.. @larsoner, can you share what exactly is going awry for you over in #15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

BackgroundPlotter not workin on Mac with vtk9

4 participants