Am 09.06.17 um 15:21 schrieb Robert Hanson:
I think we're one level off here. You can always run Jmol.jar if you
want Jmol's desktop application, and nothing is going to change about
that. It isn't an applet, so there is no browser issue.
I don't think that Jmol's current desktop application can replace the
applet. Besides the rich functionality and powerful scripting language
of Jmol in general, the strength of the applet is the flexibility to
build any interface for Jmol you want.
Take for example the Jena3D Viewer (http://jena3d.leibniz-fli.de).
Almost nothing of it's special functionalities could be transferred to
the current desktop application.
My quick read of the JavaFX tutorial
[docs.oracle.com/javafx/2/overview/jfxpub-overview.htm
<http://docs.oracle.com/javafx/2/overview/jfxpub-overview.htm>] suggests
that it is simply a newer way to build an independent Java desktop
application like Jmol.jar, but it has a wider set of user interface
capability than what we use now (Swing). Thus, they talk about being
able to insert a full-fledged webkit browser into the application, to
use CSS for styling, to dynamically create a user interface -- that sort
of thing.
And although the general Javascript performance is catching up with
Java, my observation is that it the performance is less stable. This
means that a task for example took anything from 60 seconds to 120
seconds (or even more) in the Javascript version, depending on how
the browser 'felt'. In contrast the Java version stably needed about
ten seconds, run on the same system before and after the Javascript
version.
Yes. By "felt" you mean that the browser will manage its threads
relating to tabs and other dyanamic content (e.g. ads), and it may shift
a running JavaScript app to a lower priority more likely than a running
Java application would or, in particular, then a running Java applet would.
A 1:12 performance ratio seems on the outside of what I have observed,
but I am sure that can happen. We are seeing 1:3 to 1:6 commonly.
I'm pretty sure the real benefit would be to use the WebGL option in
JSmol, or at least to develop that further. For example, by merging
NGL's excellent 3D capabilities into JSmol.
Rolf, do you have a sense of whether these slow-downs are rendering
issues? Or do they happen in relation to file opening, model
construction, or surface construction?
Rendering speed differences are rather difficult to quantify. If I
rotate or zoom into a large structure with many translucent bonds, it is
rather a qualitative shift: from almost unusable to totally unusable for
most interactive work.
My quantitative observations are related to running times of Jmol
scripts. In the Javascript version they run up to about 50 times slower
than in the Java version. My general impression (a few month ago) was
that built-in functions were running about 5 times slower than in Java,
while user-defined functions were running up to 50 times slower.
Regards,
Rolf
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
