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
