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? José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ------------------------------------------------------- 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
