VMD-L Mailing List

From: Juan Alfredo Freites (jfreites_at_ea.nacs.uci.edu)
Date: Thu Dec 11 2003 - 12:28:18 CST

On Thu, 11 Dec 2003, John Stone wrote:

> Dear Juan,
> Displaying remotely, even on a local network, typically runs at
> least 10 times slower than displaying locally. Even on the same
> LAN subnet doing remote display requires all OpenGL commands to be
> packaged up, sent over the wire, rendered, etc. The biggest performance
> hit occurs on OpenGL commands that require network round-trips such as
> state querying commands, etc. Its possible that you're seeing a bigger
> remote rendering hit on 1.8.2 because there's a once-per-frame OpenGL
> error check query in VMD 1.8.2 that wasn't in 1.8.1, which is probably
> requiring a network round-trip. This is the only thing I can think of
> that would adversely affect remote rendering performance, everything else
> that was changed in VMD 1.8.2 would cause it to do _less_ OpenGL calls and
> therefor run faster. If the OpenGL error check call is indeed responsible
> for the remote display performance hit, I'll change the ode so that it can
> be enabled or disabled dynamically with an environment variable setting or
> something similar.
>
> In any case, I'd recommend running VMD locally unless you have a strong
> reason to want to run remotely. Even disabling OpenGL error checking will
> not make remote display usable for any but simple molecular structures.
>

Thanks John. I agree with you, I don't think remote displaying is a
healthy habit. As I mentioned before, as long as there isn't any
displaying involved, I don't have any problem running vmd via ssh.
I was mostly curious about what had happened/changed. I'll
do a nfs mounting if I need to display something from the linux box.