Quoting Timothy Driscoll <[EMAIL PROTECTED]>:
The problem, of course, is not saving or replaying commands - which is fairly fast - but the number of false starts and dead-ends that
I think that you are underestimating the requirements of my Jmol interface. Take for example PDB entry '1OZT' (http://www.fli-leibniz.de/cgi-bin/3d_mapping.pl?CODE=1OZT). The slowest part is the labelling of all 502 "SAPs(SNPs)/Variants", because they all must get an individual label, not definable by a simple rule. I might be able to reduce the number of individual labels to about 70 in this case, but in other cases with a single chain there would be no reduction possible.
It takes about 45 seconds on my Laptop with a 1.6GHz Pentium M processor (approximately equivalent to a 2 GHz Pentium 5) to set and display all 502 labels. You can test this on your computer if you first switch to the 'advanced interface', then switch off the labels (if already shown) and finally switch the default labels for "SAPs(SNPs)/Variants" on.
I guess you can imagine now that this could add up to several minutes, if you would just replay all commands in the history, depending on what the user does.
Talking about size requirements now. The labelling part needs currently at least 20 KBytes (uncompressed). Therefore you might get into the range of up to 1 MByte. With only 96 MByte usually available by default for the whole Java virtual machine, this might also get an issue.
the typical user encounters while setting up a view. if you actually read the output script from PE, it quickly becomes impossible to tell what it will render in the end. but, running the script back in PE works rather well. so, one question would be: do you care about the cleanliness of the output script? do you want it to be 'human- readable' in other words? if not, the simplest method is brute force - just save every command that comes in. of course, you would have to do some rudimentary error-checking so a typo didn't bonk your saved script.
'human-readability' would not be required. But with the current possibilities it would be too unreliable, even if it would in princible be possible to sort out all error-prone commands (which I really doubt). What about commands invoked by using the popup menu of the applet itself? Or if the user would set mouse selection on? How could you possibly bring all those callback informations into the right chronological order, being reported asynchronously? Users are usually quite impatient and don't always wait until one command is finished before they invoke another one. The results were quite unpredictable (at least for me) when I tested this.
Those problems could of course be avoided, if Jmol would build up the history itself. But there still would remain the time and maybe also space requirement problem.
Regards, Rolf ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
