> Date: Sat, 21 May 2005 18:24:36 +0000 > From: Darrin Smith <[EMAIL PROTECTED]> > > Again, it isn't the decompression that is slow, nor was it the reading of the > compressed image off of the server or the transmission speed (local Intranet > witha fast network). The problem was somewhere in the applet reading the > file.
As Laurent Gilson suggested, you may want to re-assess your usage of CompressedGeometryFile. Unfortunately it was really not designed for data transmission, as you've become aware. When all this was implemented the standard Java file I/O API was horribly slow, and we had many gigabytes of CompressedGeometry objects that we wanted to be able to read and load very quickly for various projects and demos. CompressedGeometryFile was written as a highly specialized, mostly read-only mechanism for retrieving thousands of models from a compressed object library. The random access feature was an extremely important requirement for this task, and there's a significant amount of overhead that goes into creating the structure of the file when it is being written, or even when it is just being instantiated from an existing file. The code was eventually released as a Java 3D utility, but it turns out not to have been very useful outside of Sun's original purposes. Most people need a file for streaming over the Internet, and this is still possible to implement. The source code for CompressedGeometryFile is readily available and could be useful in designing and implementing a streamable version. -- Mark Hood =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
