On Feb 16, 2006, at 5:01 p, [EMAIL PROTECTED] wrote:
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.
hi Rolf,
this only took a few seconds on my machine (667 MHz G4 PPC); perhaps
I missed a step? in any case, it seemed to work because a whole lot
of labels showed up (though I did not count them). :-)
but I agree with your point - this capture and replay method would
eventually bog down as the command history became very large, and
certainly some applications would quickly enter that realm. so it is
not a universal solution by any means.
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.
yes, this is a problem. for example, what if a user labeled every
atom in a large structure? the history would have to be somewhat
intelligent, which makes it all the more difficult to design.
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.
yes, all of these issues came up during implementation of Protein
Explorer's script recorder. many of them are solvable - menu
commands could be sent through the callback mechanism just like user-
supplied commands, for example, and a buffer could ensure correct
ordering of the history. we found these problems generally solvable
in PE, but often quite difficult. of course, we did not have the
benefit of open source.
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.
yes, which is why a good solution of this type should include some
form of feedback, to keep the history as short as possible.
instead of a history, though, how about a simple tab-delimited file,
one atom per line along with all of its attributes? in this case,
the maximum size of your saved view would be the size of the original
structure file.
I think I had better duck now. ;-)
regards,
tim
--
Timothy Driscoll em: [EMAIL PROTECTED]
Virginia Bioinformatics Institute ph: 540-231-3007
Bioinformatics I im: molvisions
Washington St., Blacksburg, VA 24061
-------------------------------------------------------
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
