[User Feedback] Windows version doesn't always work

[constantinpape]

We got feedback from a windows test user that the tool does not function properly on her two windows laptops. On both machines, the points layer is not displayed and the transparency slider on the segmentation layer doesn't work.

Maybe an old OpenGL or QT version?

[constantinpape]

Too provide some more context, we have also been seeing OpenGL / QT version related issues on our VM infrastructure for windows; so this seems to be a recurring issue.
We will see if we can pinpoint this closer and let you know.

[tlambert03]

If we could get the output of napari --info that would be helpful

[tlambert03]

Oh, and btw, virtualization (weather it be via Remote Desktop or a local VM) has proven to be very difficult. The only way I’ve seen it work is to use virtualgl (which is tricky to set up): https://www.virtualgl.org/

[constantinpape]

Oh, and btw, virtualization (weather it be via Remote Desktop or a local VM) has proven to be very difficult. The only way I’ve seen it work is to use virtualgl (which is tricky to set up):

Thanks for the information. In general, this is a bit unfortunate, because running tools on a VM is a very common use-case.
cc @VolkerH

Also, here's the napari info from the gui, which the user which these issues just send me:

[tlambert03]

In general, this is a bit unfortunate, because running tools on a VM is a very common use-case.

oh yeah. we definitely commiserate!
for some background on the remote/VM discussion ... see:
napari/napari#799
napari/napari#804
napari/napari#881
napari/napari#886

one idea has been to create a napari docker container... though of course that's not as convenient.

certain quadro NVIDIA cards may sometimes be capable of remote/virtualized openGL? ... which I think @VolkerH has used right? And nvidia recently released a tool to enable openGL over RDP with GeForce on Windows10 ... but I think that failed for @VolkerH

[sofroniewn]

That vispy dependency looks funny - we are at vispy>=0.6.4 right now - not sure how a 0.5.3 popped in there? Almost certainly an 0.5 vispy will break things

[tlambert03]

oh yeah! how did I miss that?? definitely :)

[tlambert03]

ohhh... I have a possible explanation: looks like 0.5.3 is the "latest" version of vispy that is shipping from conda-forge for win32 platform: https://anaconda.org/conda-forge/vispy

so I'd be curious how this user installed (conda or not) ... and if so, whether it interpreted the machine as win-32? if it was conda, can they give us conda list?

[tlambert03]

oh, actually... looks like your pre-built windows binary has vispy0.5.3 in it (it also has napari 0.3.2 fwiw). If you're building on CI and using conda, it must be a 32 bit machine. If at all possible, you might try using as little from conda and as much from pip as possible in your build?

[constantinpape]

@k-dominik
looks like fetching napari and it's dependencies should be done via pip.
Can we change that in your installer?

[k-dominik]

oh, actually... looks like your pre-built windows binary has vispy0.5.3 in it (it also has napari 0.3.2 fwiw). If you're building on CI and using conda, it must be a 32 bit machine. If at all possible, you might try using as little from conda and as much from pip as possible in your build?

looks like there is a problem with the napari feedstock on conda-forge, it doesn't contain any dependency pins. I'm currently packaging with constructor - that's conda only afaik. It's no problem to bundle the right vispy version at all. It's there on conda-forge, too.

[tlambert03]

Ok, maybe @jni can update the feedstock. Why do you think an unpinned recipe would have used vispy 0.5.3 though? Doesn’t it seem more than a coincidence that the win-32 files only go up to v0.5.3?

[k-dominik]

Ok, maybe @jni can update the feedstock. Why do you think an unpinned recipe would have used vispy 0.5.3 though? Doesn’t it seem more than a coincidence that the win-32 files only go up to v0.5.3?

phew, that is a good question - especially since I'm building on win-64... I opened an Issue about it in the feedstock: conda-forge/napari-feedstock#7

[jni]

@k-dominik if you try conda update -c conda-forge vispy, does it fix the issue? Or does it mess with other packages?

[VolkerH]

certain quadro NVIDIA cards may sometimes be capable of remote/virtualized openGL? ... which I think @VolkerH has used right? And nvidia recently released a tool to enable openGL over RDP with GeForce on Windows10 ... but I think that failed for @VolkerH

Correct, the recently released tool from NVIDIA didn't work for us, I think this is intended when one wants to access a physical workstation that has a GeForce card and not for use on virtual machines.
In our particular case, it turns out that the Nvidia vGPU drivers are probably more appropriate and they were not yet installed (the person in our IT department is going to try that next week).

[constantinpape]

Our beta tester tried the new windows build with updated vispy again.
And indeed that fixes a lot of issues for her.
However, the points in the point layer are still not displayed!
(She tried a lot: toggling visibility, updating the layers via the u shortcut etc)

@sofroniewn @tlambert03 any ideas what might cause this?
Here is the napari info:

napari: 0.3.4
Platform: Windows-10-10.0.18362-SP0
Python: 3.7.7 (default, May 6 2020, 11:45:54) [MSC v.1916 64 bit (AMD64)]
Qt: 5.12.5
PyQt5: 5.12.3
NumPy: 1.18.1
SciPy: 1.4.1
Dask: 2.17.2
VisPy: 0.6.4

GL version: 4.0.0 - Build 10.18.10.4358
MAX_TEXTURE_SIZE: 16384

Plugins:
- covid-if-annotations: 0.0.3.dev1
- napari-plugin-engine: 0.1.5
- svg: 0.1.3