no particular bound....
You can load 1000 protein trajectories into Jmol with no problem; I don't
think there's any reason to worry about loading multiple models.
On Tue, Mar 4, 2014 at 7:22 AM, Charles Harrison Shubert
<[email protected]>wrote:
> Hi Angel,
>
> Thanks for calling me on this!
>
> As Bob points out, there is a good reason for me to SAVE state in the
> jmolObject and keep the object around. So, I think that I'll adjust my code
> to do that. It would be great if I didn't need to save anything in the
> browser's localStorage.
>
> My reason for not wanting to load all the molecules into one jmolObject is
> that I have no particular upper bound to the number of molecules that a
> user can load in my app. Different uses of Jmol will have different
> constraints.
>
> My development environment uses localhost, so I hadn't bumped into
> download from a server with a slow internet connection yet. Thanks for
> reminding me that there is a real world out there.
>
> --Chuck
>
> On Mar 4, 2014, at 4:07 AM, Angel Herráez <[email protected]> wrote:
>
> >
> > Sorry, Chuck, but I don't see the point of "throwing away the old
> > JmolObject". It's just plain easy to load a new molecule into the
> > same JmolObject.
> >
> > Have you tried the speed of your method from a distant server? My
> > experience says that initial loading of the JS code takes time, even
> > on page reload. Of course, this may not be applicable for reinserting
> > an object in the page without reload. But I see it as an unneeded
> > effort, just for switching from one molecule to another.
> >
> > Dina, there's probably not so much overload having 4 JmolObjects,
> > being Html5 JSmol, than it was when using Java.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
