Completely black ParaView user interface in VirtualBox

ParaView Support
1

Hello,
sometimes I have to work with ParaView on a Linux guest running under Virtualbox on a Windows10 host.
With ParaView 5.5 or 5.6 linux binaries downloaded from the ParaView website, the complete ParaView window is black (not just the render window), when using Ubuntu 18.04. With ParaView 5.4 or Ubuntu 16.04, I don’t have this problem.

I assume some OpenGL incompatibilities, but what is the exact reason for the black window?
Is there some environment setting that fixes the problem?
Thanks

2

Hmm, it should pop up an error message. What happens if you run with the --mesa-swr argument (there are other --mesa options as well, see --help for those).

3

Thank you,
there is no output when running paraview, just a black window.

I have the same problem on two different physical machines, one with dedicated GPU, the other with onboard graphics. It would be interesting to know, if anybody can confirm this problem for the following configuration:

At least, your workaround --mesa-swr gets me a working ParaView, also --mesa and --mesa-llvm solve the problem. What does this indicate?

Thanks
Patrick

4

It indicates that the video drivers in the guest don’t have a sufficient OpenGL implementation available. The flags turn on Mesa which has a software implementation of OpenGL.

5

I thought that osmesa is the OpenGL software implementation, but that Mesa in general just provides an interface to the 3D rendering hardware?
If I am mistaken, your answer explains why I get such bad framerates with this VirtualBox setup (and the --mesa option), although I notice no slowdown with ParaView 5.4.1 running in VirtualBox.

Does ParaView starting from version 5.5 have different OpenGL requirements compared to version 5.4? If yes, this might help me investigate how to build VirtualBox with better OpenGL support.

Thanks
Patrick

6

OSMesa is for offscreen rendering. Mesa can proxy to DRM drivers (e.g., nouveau or intel), but it also has multiple software backend including llvmpipe and swr. Generally, --mesa-swr is probably going to get the best performance.

I don’t think there were OpenGL requirement changes between 5.4 and 5.5, but I’m not sure. @utkarsh.ayachit? @martink?

7

It seems like nobody can confirm that ParaView >=5.5 works on Linux guests inside a Windows10 VirtualBox host. The software rendering using the Mesa workaround is too slow for practical purposes.

If this problem cannot be debugged, I’ll need to focus on another parallel VTK rendering engine without ParaView dependencies.
More feedback is appreciated.
Thanks
Patrick

8

Patrick
Hello. I’m not familiar with the code of this graphics stuff, but I’m almost sure that non-native OpenGL implementations are very likely to cause problems with ParaView. Unlike many “copyrastic” paid programs that change slightly and only consume money, ParaView is being actively developed so different changes may be introduced regarding OpenGL usage/requirements. If you ran ParaView 5.4 successfully inside any VM it was a great luck. I have some sort of OpenGL support via RDP (CentOS + FreeRDP links to Win7 + nVidia Quadro on workstation) and ParaView 5.2 works and shows that it uses nnVidia driver (OpenGL Version: 4.5.0 NVIDIA 377.35, OpenGL Renderer: Quadro K4000/PCIe/SSE2). But later versions doesn’t work via this RDP.
Regarding things like CFD Post that work via RDP. It’s a kind of that copyrastic software that is not developed anymore and they just suck money for the license. So they use very old OpenGL functions that doesn’t require new features. But there is nothing good in that you pay for the program that is not developed (I’m criticizing ideas here :)). I prefer ParaView even for ideological reasons, although it requires modern OpenGL support.