Re: Transfer time

Syndesis Corporation ([email protected])
Tue, 23 May 1995 11:19:26 -0500


"Nathan J. Strange" <[email protected]> writes:
>> On Sat, 20 May 1995, Nathan J. Strange wrote:
>> > compression just by translating all of the commands into 1 or 2 byte
>> > sequences, chuckin comments and whitespace and making everything binary
>>
>> Gnu-zip does this quite well.
>
>What I was proposing was a VRML specific compression algorithm
>Since we know what all the commands are, we can achieve very high
>compression,
...
>To parse it'd be something like get byte # 123 that stands for some command
>that requires 6 bytes of parameters following it, so grab the next 6 bytes
>dump them into the command and read the next byte as a command...

Does it ever seem like you're writing the same program, over and over? :-)
Or at least discussing the same things over and over on the Internet.
The techniques of computer science are well-known. Let's not
quibble about details of enums.

I think we need to focus on our goals, not the techniques.
Is compression of VRML files an important goal? So far, we've
seen many multi-megabyte VRML files that are useless to the
average Internet rube with a 28.8 modem. They give great demo
to press people when you're running on an Extreme with a T1
connection, of course. Perhaps these will not be the norm, and
VRML designers will become more and more aware of data size,
transmission speed and rendering time on the target computer.

VRML certainly could have been much more minimal and more highly
optimized... for example, I'm willing to argue that fixed-point
16-bit coordinates have enough headroom for modeling any scene you'd
actually want to watch render in real-time on today's PCs.

Storing, compressing, transmitting, de-compressing and then rendering
single-precision values represented in ASCII on 640x480 screens
certainly doesn't make much sense from an efficiency standpoint.

- John Foust