home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.amiga.graphics
- Path: sparky!uunet!mcsun!Germany.EU.net!mpifr-bonn.mpg.de!speckled.mpifr-bonn.mpg.de!mlelstv
- From: mlelstv@speckled.mpifr-bonn.mpg.de (Michael van Elst)
- Subject: Re: 30 fps: Yeay or nay?
- Message-ID: <1993Jan8.124320.995@mpifr-bonn.mpg.de>
- Sender: news@mpifr-bonn.mpg.de
- Nntp-Posting-Host: speckled
- Organization: Max-Planck-Institut f"ur Radioastronomie
- References: <1992Dec28.224231.8344@fcom.cc.utah.edu> <1992Dec29.023929.6787@mnemosyne.cs.du.edu> <Blue-Knight.04t9@bknight.jpr.com> <1993Jan1.111915.4004@midway.uchicago.edu> <10388@cbmger.de.so.commodore.com>
- Date: Fri, 8 Jan 1993 12:43:20 GMT
- Lines: 25
-
- In <10388@cbmger.de.so.commodore.com> peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany) writes:
- >Sorry, don't know about this AAP_AAC or ANIM-7 format, but generally:
- >Do you really think it would be a good move from 1 byte to longwords?
- >See, you want to compress your data. Thus your goal is to find as many
- >identical data as possible and store these only one time plus a count
- >how many times you have to replicate them in the final picture.
-
- No, at some point your goal is to utilitize the bandwidth to chip memory
- has much as possible. With 32bit wide data paths a byte oriented compression
- scheme is limited to 1/4th of the bandwidth (of course, the program
- overhead reduces that ratio a bit).
-
- >But if this particular format is much smarter, then please forget my
- >uttering and perhaps explain the trick used there.
-
- No, it isn't smarter. It usually wastes lots of bits when just a single
- byte did change, but it does this with no performance penalty if your
- data source (memory buffer or HD) can deliver the data rate.
-
- Regards,
- --
- Michael van Elst
- UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
- Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
- "A potential Snark may lurk in every tree."
-