home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / virtual / 3823 < prev    next >
Encoding:
Text File  |  1992-11-24  |  2.8 KB  |  71 lines
  1. Newsgroups: sci.virtual-worlds
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!rpi!usenet.coe.montana.edu!news.u.washington.edu!stein.u.washington.edu!hlab
  3. From: jimh@surreal.asd.sgi.com (Jim Helman)
  4. Subject: Re: TECH: DataGlove packet rate
  5. Message-ID: <1992Nov24.051824.5301@u.washington.edu>
  6. Originator: hlab@stein.u.washington.edu
  7. Sender: news@u.washington.edu (USENET News System)
  8. Organization: Home for Degenerate Physicists
  9. References: <1992Nov14.011645.11929@u.washington.edu>
  10. Date: Mon, 23 Nov 1992 19:33:02 GMT
  11. Approved: cyberoid@milton.u.washington.edu
  12. Lines: 57
  13.  
  14.  
  15.  
  16. cdshaw@cs.ualberta.ca (Chris Shaw) writes:
  17.  
  18.    Our study of this problem, published in the User Interface Software
  19.    and Technology 1991 Conference (ACM UIST'91) indicates that using
  20.    continuous mode can reduce lag by up to 50 milliseconds.
  21.  
  22. Useful paper.  Anyone interested in tracker latency, should also check
  23. out this year's UIST Proceedings.
  24.  
  25.    The key point to note here is that you should always try to eliminate
  26.    needless synchronization of the visual update upon other updates, such
  27.    as tracker update. Polling the tracker requires you to hang around
  28.    waiting for the latest data to show up. You can't always guarantee
  29.    that you can fill this time with something useful.
  30.  
  31. You certainly don't want to sit around waiting for the tracker or any
  32. other input device to sample, compute and return data.  But I'd also
  33. argue that you don't want to run in continuous mode for two reasons:
  34.  
  35.         1) Temporal jitter: You'll have a variable time between
  36.         the last sample of the tracker and the time at which
  37.         the corresponding image is drawn.  Synchronization can
  38.         eliminate this temporal jitter.
  39.  
  40.         2) Interrupts: Especially on a uniprocessor machine,
  41.         I sure don't want my CPU getting a zillion unnecessary
  42.         serial interrupts and waste time bouncing between the
  43.         kernel and my rendering code.
  44.  
  45. A better solution would:
  46.  
  47.         1) Multiprocess: Handle serial interrupts and tracker
  48.         input on a separate CPU, if available, and communicate
  49.         the results through shared memory.
  50.  
  51.         2) Just in time: Make the request to the tracker so
  52.         that the data is returned "just in time" to set the
  53.         view and object transformations for the next frame.
  54.         This keeps your latency minimized, eliminates the
  55.         temporal jitter, and reduces unnecessary interrupts.
  56.         If you're running at a fixed frame rate, e.g. using
  57.         something like IRIS Performer (plug!), knowing when to
  58.         issue the request to the tracker is fairly
  59.         straightforward.
  60.  
  61. In general, synchronization is a good thing as long as it doesn't slow
  62. you down.  Otherwise, you will have temporal jitter and need
  63. interpolation or prediction to compensate.
  64.  
  65. rgds,
  66.  
  67. -jim helman
  68.  
  69. jimh@surreal.asd.sgi.com
  70. 415/390-1151
  71.