From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: conformance question
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Wed, 16 Dec 92 20:50:20 GMT

In article <1992Dec15.204500.14333@dsd.es.com>
	rthomson@dsd.es.com (Rich Thomson) writes:
>Further, it seems that the presence of double buffering, depth
>buffering, stencil buffering and accumulation buffering isn't strictly
>required of all OpenGL implementations since the glGet() function is
>used to query the presence of these.

Yesterday I got a call from Kurt Akeley on his car phone (!)
explaining this.  The reason the OpenGL spec says this is because the
idea of a "visual" is inherent to the window system and they wanted
the core specification to be window system independent.

So, for each window system there is another specification which
requires the implementation in that window system to provide at least
one "visual" containing all the buffers (front, back, left, right,
depth, stencil, and accumulation).  This guarantees that all
functionality will be present in all conformant OpenGL implementations
under that window system.  This explains the quote from the GLX (OpenGL
under the X window system) specification that Jeff Weinstein gave.

It does appear to leave a small "loop hole" for any implementation of
OpenGL under a window system that does not yet have a specification
(for instance AmigaDOS/Intuition, or the Mac System/Toolbox).  Kurt
tells me that they are working on an NT specification.

However, it is easy to see that not all hardware accelerators have
stencil buffers and accumulation buffers in hardware.  For these
accelerators it may not make sense to have some portions in hardware
and some portions in software and the OpenGL implementation may choose
to provide the full-featured visual completely in software.  This does
not mean that the hardware is useless, however.  The implementation
may provide other visuals that have only a front, back, and depth
buffer, for instance.  This visual could be fully accelerated by the
implementation and when this visual was queried via glGet() for the
existence of a stencil or accumulation buffer, it would return False.

This is a step forward in the sense that a full-featured visual is
always guaranteed to be present in a conformant OpenGL implementation.
We still have the problem of determining which visual is the _fastest_
in a given implementation, though.  Many 3D applications are so speed
starved that they will want the fastest visual available.

I'm beginning to think that applications will still have a big
platform-specific "switch" statement figuring out which visual to use
in order to find the fastest visual.  On the other hand, I haven't
read the spec in its entirety yet, so perhaps they provide some
mechanism where the implementation can provide a "hint" as to what
visual is the fastest.

I suppose that for OpenGL under X a hint property could be set on the
root window.

						-- Rich
-- 
		      Don't blame me; I voted Libertarian.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer
Newsgroups: comp.graphics,comp.graphics.animation