Thanks. I tried it earlier but maybe I messed something up. I will try it again in front of the client tomorrow.
Actually it is not super choppy. It's actually okay for the small client. It is a local network (Wifi). I will take your advice and explore TurboVNC. I thought VirtualGL would be more lightweight so I chose it. Btw, the choppyness basically goes away when I reduce JPEG quality to 30%-50%. Wouldn't that speak against your assesment that it is the 2D part and remote X? On Tuesday, June 9, 2020 at 7:23:03 PM UTC+2, DRC wrote: > > NOTE: My e-mail client split the two commands onto different lines, but > by "concatenate", I meant enter the commands on the same line. > > On 6/9/20 12:21 PM, DRC wrote: > > On 6/9/20 8:54 AM, shoe wrote: > >> Hi, > >> > >> I successfully use VirtualGT. Great software. I already setup > >> passwordless login. Now I want it even more comfortable. > >> > >> I want to set this up for somebody who knows even less then me (sorry, > >> I am a total noob) > >> So I want them to be able to click an icon and everything works. > >> > >> So far they have to do this on the console: > >> > >> 1. /opt/VirtualGL/bin/vglconnect mys...@192.168.178.22 <javascript:> > >> (no password required) > >> > >> 2. /opt/VirtualGL/bin/vglrun -samp 4 -c jpeg -q 50 > >> Downloads/blender/blender > >> > >> > >> Can I somehow combine this into a single command? > > Yes. Just concatenate the two commands. > > > > /opt/VirtualGL/bin/vglconnect mys...@192.168.178.22 <javascript:> > > /opt/VirtualGL/bin/vglrun -samp 4 -c jpeg -q 50 > Downloads/blender/blender > > > > Basically vglconnect is a wrapper for SSH, so you can pass any SSH > > command-line options to it (including specifying a remote command to > run.) > > > > > >> P.S.: the server is quite powerful - certainly no bottleneck. The > >> client super old (although the CPU is only at ~20% when running > >> blender). Still, for example rotating objects in blender is still a > >> little choppy. I already increased responsiveness massively by > >> reducing jpeg quality. Does this mean it is most likely a bandwidth > >> issue and I cannot do anything about it? Or is it maybe the GPU of the > >> little client and not the CPU which I can monitor? I doubt it is less > >> difficult for the GPU to handle more compressed jpeg, right? Or is the > >> bigger jpeg size more demanding for the client (and not necessarily > >> the bandwidth?) > > Unless you are on a local-area network, you should not use the VGL > > Transport (vglconnect.) Use TurboVNC instead. The VGL Transport is a > > legacy feature that relies on remote X to display any non-OpenGL > > elements of the application's GUI, so the choppy behavior is likely due > > to the application updating those other elements of the GUI. Remote X, > > since it is generally a fine-grained protocol, is very sensitive to > > network latency. > > > > > -- 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 virtualgl-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/dc555c76-a0d2-4358-b755-2a7fd06645b8o%40googlegroups.com.
