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 Sivananthan Lab_LOGO 08JAN2010 small Sivananthan Laboratories, Inc. 590 Territorial Drive Ste H Bolingbrook, IL 60440 630.226.0080 630.226.0081 Fax The contents of this email and any attachments are the proprietary property of Sivananthan LaboratoriesR. The information contained within is confidential and should not be shared, sold, or distributed without explicit permission of Sivananthan LaboratoriesR. ---------------------------------------------------------------------------- -- 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
<<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
