Re: [Jmol-users] Jmol/SwingJS and JSmol update

[Robert H. <ha...@st...>]

And a comment about CheerpJ. That CheerpJ download was 21 MB. I've seen 100
MB downloaded.

Did you try "Save File"? Surface creation? Popup menus that look right? The
key is in the details.

What this method does is directly transfer Java code to WASM, without any
considerations for JavaScript's differences. I've studied it some, and it
looks like a nightmare. Maybe some small programs can run, and maybe they
can work. But this is not a general solution. They are loading huge swaths
of Java class packages. And I don't see how they can possibly be doing
anything with threads.



On Sun, Dec 13, 2020 at 5:24 PM Robert Hanson <ha...@st...> wrote:

> Well, Paul, as a matter of fact....
>
> I just got introduced to WASM in relation to InChI creation. I'm
> impressed. Turns out just this past year a mechanism was developed (LLVM)
> to compile C++ code directly to Web Assembly, with the simple hooks
> necessary to access it. It was fun learning how to do this with InChI.
>
> What do you know about how the Java code was converted to Web Assembly?
> There could be some good surface calculations that would benefit from that,
> for sure. Mostly, though, I think the calculations are not the slow part in
> JSmol. More the rendering.
>
> Bob
>
>

-- 
Robert M. Hanson
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

*We stand on the homelands of the Wahpekute Band of the Dakota Nation. We
honor with gratitude the people who have stewarded the land throughout the
generations and their ongoing contributions to this region. We acknowledge
the ongoing injustices that we have committed against the Dakota Nation,
and we wish to interrupt this legacy, beginning with acts of healing and
honest storytelling about this place.*