home *** CD-ROM | disk | FTP | other *** search
- Path: soap.news.pipex.net!pipex!usenet
- From: m.hendry@dial.pipex.com (Mathew Hendry)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: animation.datatype
- Date: Wed, 6 Mar 96 16:18:28
- Organization: Private node.
- Distribution: world
- Message-ID: <19960306.425730.EAB2@ai221.du.pipex.com>
- References: <4hjmn3$5f0@news.uni-paderborn.de> <4hk41d$kpn@news.kth.se>
- NNTP-Posting-Host: ai221.du.pipex.com
- X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
-
- Johan Forsberg (d92-jfo@nada.kth.se) wrote:
- : Thomas Schwoeppe writes
- : >In article <313C3D4F.41C6@felix.univ.szczecin.pl>, Miloslaw Smyk
- : >Are there any datatypes available that actually use animation.datatype?
- :
- : That would be hard in the extreme, thanks to the abyssmaly poor
- : animation.datatype that you have to inherit from.
- : That's why we need a new animation.datatype.
- : It should be able to:
- : Load-While-Playing (TM) ;-)
- : Use CyberGFX.
- : Scale, perhaps.
- : Be mucho more flexible, generally.
-
- The same goes for other datatypes (sound, picture etc.). An extended system
- which allowed the datatypes to work with streams (rather than complete
- datasets) and more advanced hardware would make them much more useful for some
- applications. A specific example would be Web Browsers, which at the moment
- have to download a entire graphic, sound or whatever before decoding it.
- Allowing the use of streams would also cut down on memory usage substantially.
- If you were to extend it further, simple processing features could be added.
-
- For example:
-
- picture.datatype(read)
- |
- v
- picture.datatype(scale)
- |
- v
- picture.datatype(write)
-
- with each method running simultaneously with the others in separate subtasks.
-
- This is analagous to:
-
- "giftopnm <[infile] | pnmscale [scalefactor] | pnmtogif >[outfile]"
-
- Piping methods such as this can be very efficient, both in terms of speed and
- memory usage. They could be particularly efficient on a tight operating system
- such as AmigaOS, especially if care was taken that _only_ the data relevant at
- a particular stage was available to it at that time. To use the scaling
- example again, if you wish to scale an image down to quarter size, the scale
- method would only need to store two input scanlines at a time in order to
- produce a single output scanline, which it could then pass on to the write
- method. Even in the worst case, only the scale method would be storing the
- entire image - the read and write methods would probably only require a
- smaller subset. JPEG, for example, which usually encodes 8x8 pixel blocks
- (I think - it may be 16x16), only requires 8 scanlines to be available at a
- time.
-
- With a suitably rich set of processing features, many of the operations now
- commonly found only in specialised applications could be easily integrated
- into any program supporting the extended system.
-
- -- Mat.
-