Waiter, there's a collada in my model

hello!



seeing as the collada portion of the jme-model.jar increases the jar size from 200K to 6M, i wonder if collada could be split into its own jar. that way users of apps that don't use collada would be spared the download. it's useful for me, but i don't know about anyone else.



here's a diff of build.xml to do this.



incidentally i also noticed that none of the jme jars are compressed–is that by design?



--- build.xml   30 Sep 2006 19:17:28 -0000      1.39
+++ build.xml   20 Jan 2007 23:30:51 -0000
@@ -81,7 +81,10 @@
                <jar jarfile="${jars}/jme-gamestates.jar" basedir="${class}" update="no" compress="false" includes="**/com/jmex/game/**/*.class" />
        </target>
        <target name="dist-model" depends="compile" description="generate jme jar file (model)">
-               <jar jarfile="${jars}/jme-model.jar" basedir="${class}" update="no" compress="false" includes="**/com/jmex/model/**/*.class" />
+               <jar jarfile="${jars}/jme-model.jar" basedir="${class}" update="no" compress="false" includes="**/com/jmex/model/**/*.class" excludes="**/com/jmex/model/collada/**"/>
+       </target>
+       <target name="dist-collada" depends="compile" description="generate jme jar file (collada)">
+               <jar jarfile="${jars}/jme-collada.jar" basedir="${class}" update="no" compress="false" includes="**/com/jmex/model/collada/**/*.class"/>
        </target>
        <target name="dist-scene" depends="compile" description="generate jme jar file (scene)">
                <jar jarfile="${jars}/jme-scene.jar" basedir="${class}" update="no" compress="false" includes="**/com/jmex/scene/**/*.class" />
@@ -94,7 +97,7 @@
        </target>
 
        <!-- Creates all the jME jars -->
-       <target name="dist-all" depends="dist-core, dist-terrain, dist-awt, dist-effects, dist-model, dist-sound, dist-editors, dist-font, dist-gamestates, dist-scene" description="Generate all jar files" />
+       <target name="dist-all" depends="dist-core, dist-terrain, dist-awt, dist-effects, dist-model, dist-collada, dist-sound, dist-editors, dist-font, dist-gamestates, dist-scene" description="Generate all jar files" />
 
        <target name="webdist-all" depends="dist-all" description="sign JARs for JNLP distribution">
                <signjar jar="${jars}/jme.jar" alias="jme" keystore="${webstart}/${keyStore}" storepass="${storepass}" />
@@ -104,6 +107,7 @@
                <signjar jar="${jars}/jme-font.jar" alias="jme" keystore="${webstart}/${keyStore}" storepass="${storepass}" />
                <signjar jar="${jars}/jme-gamestates.jar" alias="jme" keystore="${webstart}/${keyStore}" storepass="${storepass}" />
                <signjar jar="${jars}/jme-model.jar" alias="jme" keystore="${webstart}/${keyStore}" storepass="${storepass}" />
+               <signjar jar="${jars}/jme-collada.jar" alias="jme" keystore="${webstart}/${keyStore}" storepass="${storepass}" />
                <signjar jar="${jars}/jme-scene.jar" alias="jme" keystore="${webstart}/${keyStore}" storepass="${storepass}" />
                <signjar jar="${jars}/jme-sound.jar" alias="jme" keystore="${webstart}/${keyStore}" storepass="${storepass}" />
                <signjar jar="${jars}/jme-terrain.jar" alias="jme" keystore="${webstart}/${keyStore}" storepass="${storepass}" />

Agreed, this was the plan, just never gotten around to. Thanks for the diff.



The jars were never compressed due to performance (webstart) reasons. However, I'm not sure how much of a factor this is (if any) nor can I remember doing any research on the subject. It's one of those "there was a reason at the time, and it was a good one" moments. If you (or anyone else) knows for a fact that compression has no effect on performance, then yes, we should be compressing. I'll do some research on this soon if someone doesn't come forward.

I don't see how compression can not have an effect on performance as surely the jars must be uncompressed before they are used?



However the fact the jars are compressed means they would transmit to the client machine faster which would surely negate the extra processing done to uncompress them?



As you've probably noticed I have no idea (in general  :stuck_out_tongue: ), am just throwing ideas out!

yes, but how often do you transfer the jars, compared to how often the VM loads classes?

yes, but how often do you transfer the jars, compared to how often the VM loads classes?


... each time You read them from disk into memory ?
I really think we should run some tests to verify performance on this.
winkman said:

... each time You read them from disk into memory ?


well, that's what i meant. while you will probably download most of the jars only once, the VM will have to read them every time. if one can guarantee that all classes are loaded at startup and not in the middle of the game then well, you can trade less transferred bytes for a slower startup. otherwise it would be quite bad if, for example, the VM does heavy decompression in the middle of some action scene.