home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / hp / 14291 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  1.3 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!ut-emx!tivoli!TIVOLI.COM!stuart
  2. From: stuart@TIVOLI.COM (Stuart Jarriel)
  3. Newsgroups: comp.sys.hp
  4. Subject: Re: Graphics accelerator slow ?
  5. Message-ID: <7157@tivoli.UUCP>
  6. Date: 21 Dec 92 23:46:00 GMT
  7. References: <1992Dec17.133718.50045@ccvax.ucd.ie>
  8. Sender: news@tivoli.UUCP
  9. Organization: Tivoli Systems, Inc
  10. Lines: 24
  11.  
  12. In article <1992Dec17.133718.50045@ccvax.ucd.ie>, njconway@ccvax.ucd.ie writes:
  13. |> 
  14. |> Weird problem:
  15. |> 
  16. |> we have 3 9k400's - two of them have been upgraded to 68040's along with a
  17. |> 98705 graphics 'accelerator' - i think this box is Personal PRX P1 or something
  18. |> like that.
  19. |> 
  20. |> the other 400 is just a 68030 with the standard graphics card A1416A (written
  21. |> on back)
  22. |> 
  23. |> now the weird bit -  i've been starting to use them heavily again (after using
  24. |> a 700 for ages) and noticed that the two 'fast' 400's take ages to update the
  25. |> screen compared to the 'slow' one. 
  26. |> 
  27. |
  28.  
  29. The PVRX accellerator's are pretty good for 3d shaded images, but for normal
  30. X work (including but not limited to getimage/putimage) they are slow compared
  31. to an 'unaccelerated' board.  This is partially due to the speed at which the
  32. CPUcan write into the frame buffers.  Unfortunately, if you are not doing
  33. 3d type work, or solids, the PVRX is just going to feel slow.
  34.  
  35. stuart
  36.