On Tue, Mar 11, 2003 at 12:01:16AM +0000, Keith Whitwell wrote:
Jon Smirl wrote:
--- José Fonseca <[EMAIL PROTECTED]> wrote:
Yes, this works as you say _if_ the method isn't virtual, or at least the exact type of the class is known at compile time, i.e., it's not an abstract Context *, but actually a non-abstract RadeonContext *.
It works for virtual methods and abstract classes. Check out a description of how C++ VTables work. This is a very integral part of how COM/XPCOM work too.
I didn't really understand where this was coming from. I think it might relate to the earlier misunderstanding that the GL dispatch tables provide a 'ctx' argument (which might be a C++ object). This isn't true -- dispatch doesn't add any new arguments, so this trick probably doesn't help.
Sorry, my fault... the Mesa dd_function_table has them, and somehow I though the glapi did the same (by picking the current ctx before calling).
This completely eliminates any doubts regarding the possibility of
passing methods.
On the other hand, for most cases in _glapi we can simply pass them static method pointers and get the current ctx via the gpapi. Eliminating the need of templates for that.
Anyway, the solution I presented here may be usefull for other functions tables in mesa, such as for the software tnl module.
But now moving the discussion forward, concerning giving more control over the glapi table to the drivers (instead of mesa). If I understood correctly, the idea is having one (or more) function tables per context. But then how things such as multi-threading and context switches work? Are there any provision in glapi for this?
Display list compilation is currently the only time we switch tables -- look at _mesa_NewList() in dlist.c. It's a straightforward operation, complicated only slightly by threading concerns.
The work I've been doing in the vtx-0-1-branch will make greater use of dispatch table switching.
Keith
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
