Allen Akin wrote:
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.

Ah yes, I hadn't thought about that aspect of it. That's pretty compelling.


Keith



-------------------------------------------------------
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