home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!europa.asd.contel.com!emory!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!ddj
- From: ddj+@cs.cmu.edu (Doug DeJulio)
- Newsgroups: comp.sys.next.hardware
- Subject: Re: New RISC workstations / 88110 demise
- Message-ID: <BxGEsK.Kwr.2@cs.cmu.edu>
- Date: 9 Nov 92 14:55:31 GMT
- Article-I.D.: cs.BxGEsK.Kwr.2
- References: <1992Nov5.070604.2071@cubetech.com> <BxBCpM.65B.2@cs.cmu.edu> <ceynlZy00WAy810IZ5@andrew.cmu.edu>
- Sender: news@cs.cmu.edu (Usenet News System)
- Organization: School of Computer Science, Carnegie Mellon
- Lines: 28
- Nntp-Posting-Host: itc.cs.cmu.edu
-
- >You can do reasonable realtime operations (such as animation) under the
- >current Mach kernel (Version 2.6 on NeXTs, I believe).
-
- "Reasonable" realtime operations? It's either realtime or it isn't.
- Right now it isn't.
-
- > Try looking at the DPSTimedEntry stuff. There are examples from NeXT
- > where at each frame, the animation code checks the actual time delay
- > from the last frame, and generates the next frame accordingly. This
- > means that the frame rate is not constant, but animated objects have
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Then it's not realtime. It would not be good enough, for example, for
- controlling scientific instruments or operating CAM machinery. And
- often it would not be good enough for a lip-synched video that had
- been digitized. It'd look like a Saturday afternoon kung-fu movie.
-
- > constant velocity and could be sync'ed reliably with sound. This is
- > generally acceptable if the CPU(s) can generate a reasonable frame
- > rate considering the other loads on the system.
-
- There's no way you can guarantee that. On a workstation like the
- NeXT, being sold to ordinary folks, the animation has to look good and
- smooth *even* *if* they're running a heavy Mathematica process in the
- background, or else it won't look good up against Macs and PCs with
- this capability.
- --
- Doug DeJulio
- ddj+@cmu.edu
-