home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / graphics / opengl / 215 < prev    next >
Encoding:
Text File  |  1992-12-16  |  3.5 KB  |  72 lines
  1. Newsgroups: comp.graphics.opengl
  2. Path: sparky!uunet!orca!mesa!rthomson
  3. From: rthomson@mesa.dsd.es.com (Rich Thomson)
  4. Subject: Re: conformance question
  5. Message-ID: <1992Dec16.205020.2674@dsd.es.com>
  6. Sender: usenet@dsd.es.com
  7. Nntp-Posting-Host: 130.187.85.21
  8. Reply-To: rthomson@dsd.es.com (Rich Thomson)
  9. Organization: Design Systems Division, Evans & Sutherland, SLC, UT
  10. References: <1992Dec15.074053.1837@dsd.es.com> <1992Dec15.080609.26325@microunity.com> <1992Dec15.204500.14333@dsd.es.com>
  11. Date: Wed, 16 Dec 92 20:50:20 GMT
  12. Lines: 58
  13.  
  14. In article <1992Dec15.204500.14333@dsd.es.com>
  15.     rthomson@dsd.es.com (Rich Thomson) writes:
  16. >Further, it seems that the presence of double buffering, depth
  17. >buffering, stencil buffering and accumulation buffering isn't strictly
  18. >required of all OpenGL implementations since the glGet() function is
  19. >used to query the presence of these.
  20.  
  21. Yesterday I got a call from Kurt Akeley on his car phone (!)
  22. explaining this.  The reason the OpenGL spec says this is because the
  23. idea of a "visual" is inherent to the window system and they wanted
  24. the core specification to be window system independent.
  25.  
  26. So, for each window system there is another specification which
  27. requires the implementation in that window system to provide at least
  28. one "visual" containing all the buffers (front, back, left, right,
  29. depth, stencil, and accumulation).  This guarantees that all
  30. functionality will be present in all conformant OpenGL implementations
  31. under that window system.  This explains the quote from the GLX (OpenGL
  32. under the X window system) specification that Jeff Weinstein gave.
  33.  
  34. It does appear to leave a small "loop hole" for any implementation of
  35. OpenGL under a window system that does not yet have a specification
  36. (for instance AmigaDOS/Intuition, or the Mac System/Toolbox).  Kurt
  37. tells me that they are working on an NT specification.
  38.  
  39. However, it is easy to see that not all hardware accelerators have
  40. stencil buffers and accumulation buffers in hardware.  For these
  41. accelerators it may not make sense to have some portions in hardware
  42. and some portions in software and the OpenGL implementation may choose
  43. to provide the full-featured visual completely in software.  This does
  44. not mean that the hardware is useless, however.  The implementation
  45. may provide other visuals that have only a front, back, and depth
  46. buffer, for instance.  This visual could be fully accelerated by the
  47. implementation and when this visual was queried via glGet() for the
  48. existence of a stencil or accumulation buffer, it would return False.
  49.  
  50. This is a step forward in the sense that a full-featured visual is
  51. always guaranteed to be present in a conformant OpenGL implementation.
  52. We still have the problem of determining which visual is the _fastest_
  53. in a given implementation, though.  Many 3D applications are so speed
  54. starved that they will want the fastest visual available.
  55.  
  56. I'm beginning to think that applications will still have a big
  57. platform-specific "switch" statement figuring out which visual to use
  58. in order to find the fastest visual.  On the other hand, I haven't
  59. read the spec in its entirety yet, so perhaps they provide some
  60. mechanism where the implementation can provide a "hint" as to what
  61. visual is the fastest.
  62.  
  63. I suppose that for OpenGL under X a hint property could be set on the
  64. root window.
  65.  
  66.                         -- Rich
  67. -- 
  68.               Don't blame me; I voted Libertarian.
  69. Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
  70. UUCP: ...!uunet!dsd.es.com!rthomson            Rich Thomson
  71. Internet: rthomson@dsd.es.com    IRC: _Rich_        PEXt Programmer
  72.