On Sat, Mar 22, 2003 at 07:24:15PM +0000, José Fonseca wrote:
| Also, I can't help thinking that some of these tricks wouldn't be
| necessary if the OpenGL standard had chosen to pass opaque pointers
| (i.e., handles) to contexts and textures, instead of using concepts such
| as "current context" and "texture names", but this is OT anyway.

The history behind the design goes something like this.

3D drawing operations require a lot of state information.  (Much more
than is typical for OS I/O services or 2D graphics.)  In the Olden Days
fast memory was hideously expensive, so there wasn't much hardware
support for multiple sets of state.  It made sense to expose the state
to the application, which could then help minimize the number of
unnecessary state changes.

It also made sense to design the API so that it was hard for app
developers to accidentally invoke expensive state updates or update
optimizations.  If the API had been designed to pass a "current context"
handle as an argument to each OpenGL command, the OpenGL library would
have to detect when a new context had been used, then "diff" the current
and new contexts to generate an efficient set of state updates.  Just
checking a cache for the context used on the last command involves a
fetch from thread-local storage, and state-diffing is a pretty slow
process.  A better approach seemed to be to fetch the current context
from thread-local storage in the first place, and isolate state-diffing
to a relatively heavyweight "context change" operation that would have
to be requested explicitly.

The current-context approach and the separate dispatch table were both
influenced by experience with X11, which itself was influenced by
experience with early versions of Windows.  (And other systems that I
don't recall at the moment.)

In retrospect, it might have been nice to expose the dispatch table to
the application (perhaps like COM interfaces).  That could eliminate one
level of indirection and it might handle extensions more cleanly.  But
it introduces new problems, and I'm not sure about the tradeoffs.

Allen


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to