Think simple instead of complicated :-)
Thank you very much, the port was blocked!
On Wednesday, February 20, 2019 at 7:13:16 PM UTC+1, DRC wrote:
>
> -c proxy is designed for use with an X proxy (such as TurboVNC, the X
> proxy we produce), so it's not surprising that it performs poorly over a
> remote connection. X proxies act as virtual X servers, so they are
> designed to be run on the same machine as VirtualGL. As such, -c proxy
> sends the rendered frames from VirtualGL to the X server using
> XShmPutImage(), so the frames are not compressed in any way.
>
> Check the vglconnect log (in {home directory}/.vgl/ on the client
> machine) and see whether vglclient actually received a connection from
> the server. If it didn't, then I would suspect that you need to open
> port 4242 in the client's firewall. This is one of many reasons why X
> proxies are the most popular way of running VirtualGL these days, but I
> acknowledge that the VGL Transport still has its uses and is the most
> straightforward way of running VirtualGL if you are already using a
> remote X environment with a client-side X server.
>
> DRC
>
>
>
--
You received this message because you are subscribed to the Google Groups
"VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/virtualgl-users/1f5c7dae-d3a1-4e5b-9234-2400ce3e034a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
