OK -- so start that one with -a 0
and you will be trouble-free. On Wed, Apr 9, 2014 at 10:30 AM, Anthony Ciani <[email protected]>wrote: > I'll take a look, but maybe later today or tomorrow. > > > > > > I use Jmol in two ways, both unmodified. Usually running locally with > data files shared over the LAN from the cluster, and sometimes running > remotely on the HPC resource, either over the LAN (cluster at work) or WAN > (supercomputer). I generally run on the cluster if I need to display a > large number of atoms, or on the supercomputer because files are too large > or methods too cumbersome to transfer data efficiently. > > > > This is natively handled by standard GUIs, such as Windows (remote via RDP > or X), Mac OS (with X installed) or just X. The client (running program) > and server (display device) can be on the same (e.g. workstation) or on > different (e.g. HPC cluster / workstation) machines. Regardless of whether > the client and server are on the same system, the drawing commands are > communicated from the client program to the display server, and inputs are > communicated from the display server to the client program. The only > difference between a local and a remote session is that when local, data is > transferred over system sockets or library calls, and when remote, data is > transferred over TCP/IP sockets. The remote display interface is > transparent, but there is a noticeable lag between input events and display > updates, even on a fast LAN. > > > > Oh yes, and this is probably why the 100 ms repeat causes so many frames > to be skipped. Even though the server might poll the mouse every 8 ms, the > client time slicing and communication delay between the client and server > (even on the same machine) could cause several hundred ms of wall time to > pass between the client program processing the mouse events. I used xev to > log mouse events between cluster and workstation on the corporate LAN, and > the fastest I could get was 15 ms apart, and xev is very light weight (i.e. > all it does is print messages). Jmol has to highlight a toolbar button, > increment a frame and set a timeout before it gets to process the next > mouse event, and that might take a lot of time when the display is across a > slow network, and possibly more than 100 ms when on a local machine. > > > > *From:* Robert Hanson [mailto:[email protected]] > *Sent:* Tuesday, April 08, 2014 9:34 PM > > *To:* [email protected] > *Subject:* Re: [Jmol-users] Frame Next and Previous Buttons Sticky > > > > Try what is up as > http://chemapps.stolaf.edu/jmol/zip/jmol-14.1.14_2014.04.08b.zip and tell > me what you think. > > What exactly are you doing? Are you somehow running Jmol.jar remotely > instead of on your own machine? There is no "client/server" aspect to > Jmol.jar that I am aware of. > > Anyway, I'm hoping 500 ms is long enough to prevent what you are seeing. > Who holds a button down for half a second? > > Bob > > > > On Tue, Apr 8, 2014 at 9:05 PM, Anthony Ciani <[email protected]> > wrote: > > I mean that there is enough delay within the network that there could be > two or more seconds between the Jmol running on the server polling the > button press on the client, updating the display, and then polling the > button release. > > > > Yes, running an X11 program over the WAN is a very slow interface. > Although it is also generally better to use the frame command than the > increment/decrement buttons over such a slow display. > > > > I was basing the 1.0 second delay on the number of frames that typically > passed in a single click with the 100 ms timeout. On the Windows box, 1 > click was generally advancing 6 or 7 frames, sometimes 9. If I quickly > slapped the mouse button, I averaged around 1.5 frames. > > > > *From:* Robert Hanson [mailto:[email protected]] > *Sent:* Tuesday, April 08, 2014 6:31 PM > *To:* [email protected] > *Subject:* Re: [Jmol-users] Frame Next and Previous Buttons Sticky > > > > Not sure what you mean by "button response in 2 seconds" -- it's a button. > It responds immediately. I'll get a version up with the 0.5-second delay > and see what you think. It's not supposed to be fancy. Just a small > convenience and preferably not a nuisance. > > > > On Tue, Apr 8, 2014 at 5:12 PM, Anthony Ciani <[email protected]> > wrote: > > A variable would be best if you want to allow quick animation using the > toolbar. > > > > Perhaps between the Frame Previous and Frame Next buttons, place a 4-digit > wide input or pull down box to specify delays between 0 (default) and > 9999-ms, or maybe 0 to 5000 in steps of 50? > > > > Although the proposed press-and-hold (I would go for 1 second delay) > change is better than the current click-and-race, I would prefer one click > = one frame, until you can make it user selectable. I use Jmol across a > large number of platforms and network types, often to check on the progress > of very large MD simulations. Over some networks, even a timeout of 10.0 > sec could skip frames (although button response is usually under two > seconds). > > > > > > > > > > *From:* Robert Hanson [mailto:[email protected]] > *Sent:* Tuesday, April 08, 2014 12:23 AM > > It's a 100-ms repeating timeout. > > @Override > public void mousePressed(MouseEvent e) { > vwr.evalStringQuiet(script); > vwr.evalStringQuiet("timeout '__animBtn' -100 \"" + script + "\""); > } > > @Override > public void mouseReleased(MouseEvent e) { > vwr.evalStringQuiet("timeout '__animBtn' OFF"); > } > > I suppose we could set that to 200 ms or, better, a variable. > > Bob > > > > > > On Mon, Apr 7, 2014 at 5:12 PM, Anthony Ciani <[email protected]> > wrote: > > Dear Jmol Users, > > > > The Frame Next and Frame Previous buttons seem to have become sticky. > They continually advance (or recede) frames until the mouse button is > released or the mouse is moved off of the icon. Behavior is seen on > Windows, Linux (remote and local Xserv), different Java versions. > > > > I could see this being a desirable feature, for example, if someone wanted > an easy way to animate frames, but frames are updated so rapidly that a > single mouse tap could do 4 or 5 frames. On a slow display interface (e.g. > X11 over a local network), dozens of frames might be updated, slowly, after > a single click. The situation is almost unbearable if used over a slow > network. If "Animate Forward" and "Animate Backward" buttons are desired, > they should be separate on the menu bar, along with a Frame Rate box. > > > > This "feature" seems to have been present since 13.0.1. I did some > searching and found a couple messages about it, but nothing happened. The > frame command inside the console works as expected. It is only the buttons > that have become sticky. > > > > > > > > > > *Anthony Ciani* > > *Postdoctoral Fellow* > > [image: Sivananthan Lab_LOGO 08JAN2010 small] > > *Sivananthan Laboratories, Inc.* > > *590 Territorial Drive Ste H* > > *Bolingbrook, IL 60440* > > *630.226.0080 <630.226.0080>* > > *630.226.0081 <630.226.0081> Fax* > > > > The contents of this email and any attachments are the proprietary > property of Sivananthan Laboratories(R). The information contained within is > confidential and should not be shared, sold, or distributed without > explicit permission of Sivananthan Laboratories(R). > > > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Jmol-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jmol-users > > > > > -- > > Robert M. Hanson > Larson-Anderson Professor of Chemistry > St. Olaf College > Northfield, MN > http://www.stolaf.edu/people/hansonr > > > If nature does not answer first what we want, > it is better to take what answer we get. > > -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Jmol-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jmol-users > > > > > -- > > Robert M. Hanson > Larson-Anderson Professor of Chemistry > St. Olaf College > Northfield, MN > http://www.stolaf.edu/people/hansonr > > > If nature does not answer first what we want, > it is better to take what answer we get. > > -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Jmol-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jmol-users > > > > > -- > > Robert M. Hanson > Larson-Anderson Professor of Chemistry > St. Olaf College > Northfield, MN > http://www.stolaf.edu/people/hansonr > > > If nature does not answer first what we want, > it is better to take what answer we get. > > -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Jmol-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jmol-users > > -- Robert M. Hanson Larson-Anderson Professor of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
<<inline: image001.jpg>>
------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
