In my understanding, there are two ways to use paraview for remote rendering. Method A is to run a paraview server and connect to the server. Method B is to connect to the remote desktop running paraview through VNC and then use the paraview instance installed there.
Being a visualization research person, I like good quality for visualizations especially for medical data. I am trying to understand about the disadvantages of using Method B. I am listing some disadvantages (maybe I am wrong) of Method B. Could you please add more disadvantages of Method B? Am I missing any other significant disadvantage of Method B.
1. Low Image Quality: VNC uses remote desktop streaming, which may reduce the image quality. REmote rendering tools like Slicer3D, paraview, Visit etc has better image quality. 2. High network,CPU load: There will be added overhead and lack of system performance when one tries to render the whole desktop instead of using the built-in render server. 3. Only one user at a time: Since Method B is a desktop connection, only one user will be able to use the desktop. However if you consider Method B, it may be possible to collaborate on the same visualization added in a notebook using future versions of jupyterhub which will have collaborative notebook environments. 4. ???
Please add more points if you know something more about this.
Please correct me if I am wrong somewhere. Also, if you think Method A is better than Method B, please list some reasons there as well.
Running ParaView on a remote desktop is a fine solution, and I have heard good success from administrators that use this approach. In fact, you can probably get faster frame rates using a remote desktop than through the native ParaView client-server socket.
I would say the biggest reason the material you see describes connecting to ParaView server directly (Method A) is because a remote desktop is not always available. I know that many facilities provide remote desktops to aid accessing their systems, and if this is a system you help manage then adding one is not a big deal. But some facilities only really support ssh access to login nodes. In this case, tunneling a socket connection through SSL, while not easy, is more universally doable than installing a remote desktop everywhere.
A second reason is that you often have to set up ParaView client/server even if you are using remote desktop. If you have a small enough problem that can run on the remote desktop alone, then fine. But bigger problems still require running a parallel pvserver and connecting that to the GUI client running on the remote desktop (whose GUI is then scraped to the user’s desktop). There are advantages to doing this, but it means setting up multiple completely different systems. This complicates writing howto instructions.
A third reason is that the direct client/server connection is easier to support from the ParaView developers/maintainers perspective. You can today download ParaView to your desktop, click on Connect → Fetch Servers and get a list of configuration scripts to connect to a number compute facilities. This provides a consistent means for developers to support users at different facilities, which simplifies things for both developers and users.
So, in summary (tl;dr), a direct ParaView client/server connection (Method A) is not any better than connecting through a remote desktop (Method B). It’s just that the people who wrote that documentation used Method A, so that is what they wrote.