by the way, if you are only showing one model at a time, you can use
save orientation xxx
restore orientation xxx
to return the previous orientation.
Generally, though, what is usually done is
save state xxxx
restore state xxxx
There does exactly what you think -- but it can take time if there are
surfaces involved.
If you have complex surfaces, you should use
isosurface cache
to change them to a highly compressed wickedly fast format for redisplay.
These are then cached in memory and called back almost instantly.
Bob
On Mon, Mar 3, 2014 at 8:00 PM, Charles Harrison Shubert
<[email protected]>wrote:
> Hi Dina,
>
> I've been experimenting with both of these approaches to loading molecules
> with Jmol over the week. Both approaches are very fast. Originally I
> thought that it would be faster if I had only one jmolObject (applet) for
> all the molecules, zapping the old molecule before loading the new one. In
> the last day or so, I decided to try using one jmolObject per molecule. I
> think that using one jmolObject (applet) per molecule makes my code
> simpler, particularly when switching between molecules in the show/hide
> approach. When I switch between molecules, I throw away the old jmolObject
> with its supporting html and reconstruct the supporting html with a new
> jmolObject. I keep my scripts and rotation information tucked away in a
> browser localStorage JSON data structure that I call "model". While this
> may seem like a wasteful approach, it is simple, very robust, and fast, due
> in no small part to the speed that Jmol loads molecules.
>
> --Chuck
>
> On Mar 3, 2014, at 8:21 PM, Dina Schneidman <[email protected]> wrote:
>
> > Hi,
> >
> > I need to display several structural models. I can do it in several
> > JSmol windows (4 windows should be enough) or in a single one (with
> > buttons to show/hide specific models). Which option will load faster?
> >
> > Thanks!
> > Dina
> >
> >
> ------------------------------------------------------------------------------
> > Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> > With Perforce, you get hassle-free workflows. Merge that actually works.
> > Faster operations. Version large binaries. Built-in WAN optimization
> and the
> > freedom to use Git, Perforce or both. Make the move to Perforce.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Jmol-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> 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
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
