On Thursday 11 December 2003 16:40, Miguel Howard wrote: > This message is about the current statue of Jmol + CDK in the area of IO > and file type support. > > So far, the beta test releases of Jmol v10 have been limited to reading > .xyz, .mol, and .pdb files. This is because Jmol is not using the CDK > libraries to do the file IO. > > The problems are jar size, memory size, speed, JVM compatibility, and > functionality. > > > jar size > -------- > jar size is not an issue for the Jmol application. > > But size is a an important issue for the JmolApplet. We want people to > build web sites where casual users can go and look at molecules. And we > already have people asking about a 'local install' so that the applet > doesn't have to be downloaded to their machine. > > 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. > 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... > In older versions of Jmol there were separate libraries required for CML > support. I was opposed to having the webmaster add a list of .jar files > because it confuses web developers. But I think I am now resigned to > having JmolApplet.jar and JmolApplet2.jar That's a small example of what a good build system could offer... > runtime size > ------------ > The CDK data structures are rather large. Have a look at the lazyCreation patch... it should make the memory footprint of the ChemObject class a lot smaller, though I have not been able to confirm that with experiments with Jmol yet... (see email on wednesday...) > My goal is to extend the JmolModelAdapter API so that the CDK data > structures could optionally be released once the model is loaded into > memory. This would make it easier for a simple viewing application to take > advantage of the CDK IO facilities, then release that memory for other > uses. 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... > 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... > I think this could be much worse when the JmolApplet is running on an > older JVMs. > > > JVM compatibility > ----------------- > I have seen some evidence that there will be problems with the CDK > libraries on older JVMs. An easy example is the fact that some of the > method names need to change ... methods for java.util.Vector, for example. 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...) > 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... > Functionality > ------------- > The primary area (perhaps the only area) where this applies is with .pdb > files. CDK would need to be extended to read additional pdb record types > in order to support the kind of functionality that is needed by the > RasMol/Chime scripting language. > > 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... > Summary > ------- > This is the current state of Jmol + CDK IO integration ... or lack of > integration. Yes, it's one of the main areas that need attention right now. To all: all help is appreciated! > I am not really looking for any specific answers. But any > feedback/thoughts/ideas/suggestions/moral support would be appreciated. I would like to add: patches are appreciated too! Egon -- [EMAIL PROTECTED] PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 ------------------------------------------------------- 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
