home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / windows / x / pex / 486 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  2.2 KB
  1. Path: sparky!uunet!mcsun!uknet!mucs!lilleyc
  2. From: lilleyc@cs.man.ac.uk (Chris Lilley)
  3. Newsgroups: comp.windows.x.pex
  4. Subject: Re: PEXtk 1.0 Test Programs
  5. Message-ID: <5855@m1.cs.man.ac.uk>
  6. Date: 21 Aug 92 14:03:43 GMT
  7. References: <1992Aug20.132131.9585@uoft02.utoledo.edu>
  8. Sender: news@cs.man.ac.uk
  9. Organization: Dept Computer Science, University of Manchester, U.K.
  10. Lines: 41
  11.  
  12. In article <1992Aug20.132131.9585@uoft02.utoledo.edu> evaleros@jupiter.cse.utoledo.edu (Elsa S. Valeroso) writes:
  13.  
  14. >    I have just compiled PEXtk Version 1.0 based on DEC Contrib PEXlib 5.0
  15. >    on one of our Sun SPARC station IPCs. I ftp'd the source code and the 
  16. >    library from export.lcs. 
  17.  
  18. >    My question is: "When I execute any of the test programs, shouldn't the
  19. >    workstation be clear of any previous images drawn by a previous test 
  20. >    program? 
  21. >    [...]
  22. >    current one. It seems that the problem lies in the double-buffering. 
  23. >    Test programs which do not use double buffering seem to be working 
  24. >    fine.
  25.  
  26. Depends on the PEX server you are using. I believe that SunPHIGS2.0
  27. only supports double buffering on graphics accelerators that have it
  28. in hardware. ie, not IPCs, you need a SPARC2 with GS or GT
  29. accelerator.
  30.  
  31. The SunPEX server extension is based on the PEX SI although with
  32. optimisations for their various accelerators. I guess (we have yet to
  33. get our hands on the Sun PEX server) that they will use the same logic
  34. as with Sun PHIGS - support double buffering only on their better
  35. graphics accelerators.
  36.  
  37. If you are using the PEX consortium SI, well that does not support
  38. double buffering or HLHSR *at all*. It is a code sample; designed to
  39. be read as much as run.
  40.  
  41. So your diagnosis seems completely correct - programs that use double
  42. buffering will fail. You have not done anything wrong, this is the
  43. expected behaviour.
  44.  
  45. --
  46. Chris Lilley
  47. ---------------------------------------------------------------------------
  48. Technical Author, ITTI Computer Graphics and Visualisation Training Project
  49. Computer Graphics Unit, Manchester Computing Centre, Manchester, UK
  50. Internet:   lilley@cgu.mcc.ac.uk        Janet:   lilley@uk.ac.mcc.cgu
  51. Voice:      +44 (0)61 275 6095          Fax:     +44 (0)61 275 6040
  52. ---------------------------------------------------------------------------
  53.