>> Linking with the CDK libraries almost doubles the size of the >> JmolApplet: >> >> JmolApplet.jar with SimpleModelAdapter 347,148 bytes >> JmolApplet.jar with CdkJmolModelAdapter 656,664 bytes > > The functionality is more than doubled... CDK has more IO formats > supported.
True. And that is important for some people. >> So, I am still trying to come up with a scheme to split the applet >> into two .jar files, where the second one is downloaded only if >> needed. I still do not have this working properly. > > We could also have a solid build system where people can define which IO > formats the applet should support... I think that most people who want to use the applet do *not* want to build it. And I certainly don't want to respond to all their email questions :-) > That's an option... it might be better to see how the CDK classes can be > improved... they have not been optimized for memory or speeds or > whatever so far... In my opinion this certainly needs to be done. > >> speed >> ----- >> Larger data structures usually mean more CPU overhead. Using the >> application, reading in hemoglobin is 8-10 times slower using CDK. > > This includes partly reading is I understood correctly... Or are these > numbers applicable to just the rendering speed when rotating... This only applies to reading the file into memory. Once Jmol has the data structures in memory, the rotation/execution speed is not affected. >> CDK compiles on 1.3... Patches to have classes compile on 1.2 are > accepted... For classes for which that does not work with a simple patch > (e.g. Vector.addElement() instead of Vector.add()...), those are > excluded from compiling... This is what happens for 1.3, and can be > used for 1.1 JVM's too... > > (If only I had a JVM 1.1 installed on my machine...) This goes back to an improved build system. I do not like the patch mechanism because my productivity goes down the toilet. Emacs (and presumably any IDE) doesn't work because the filenames/line numbers are incorrect. >> A harder example is the use of exceptions. As I recall, the last time >> I tried to get CDK to run in the JmolApplet I was getting exceptions >> on the NS JVM. Eliminating this type of problem will be slow, painful, >> and frustrating. > > Note that has been always the case... also when Jmol was still Jmol, and > had nothing to do with CDK yet! Browser JVM's are a problem an sich... I have put in a *lot* of energy to ensure that Jmol can run on a wider variety of JVMs. I would hate to think that all that work was wasted. >> I tried to make some of these changes about a month ago, but I ran >> into difficulties, got frustrated, and postponed the work. > > Let's coordinate this... Tell me which changes you need, we'll discuss > them on the CDK mailling list, and get things done... OK. Let's talk about the patch-build mechanism on cdk-devel. Miguel ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
