Ian Romanick wrote:
I know this is a breach of protocol, but I'd like to discuss the patch that I have for this before attaching it to the bug report or committing it.
In both the client-side and the server-side g_render.c I have created some template macros for generating the GLX protocol stubs. The client-side version was 3,600 lines of virtually identical code. That bugs me. If nothing else, it makes it difficult to determine which functions exist and which ones don't. It also makes the process of adding new functions tedious and error prone. I suspect that these files may have been automatically generated at one point, but the means for doing that are lost. After committing this fix, I intend to convert almost all of the client-side g_render.c functions to use some form of template.
I would also like to eliminate indirect_wrap.h. The only place that seems to be needed is in g_render.c and vertarr.c. The templates will allow it to be eliminated from g_render.c, and it should be easy enough to modify vertarr.c.
My server-side goals are slightly more ambitious. I intend to create a new header-file, dispatch_stubs.h or some such, that contains all of the templated functions. Under normal circumstances, the templates will generate the __glxDisp_ and __glxDispSwap_ prototypes for the functions. If the file is included and GLX_GENERATE_CODE is defined, the functions will be generated. A new C file, dispatch_stubs.c, will be the only file to define GLX_GENERATE_CODE. It will also contain the few functions that can't easilly be templatized. g_render.c (server-side only), g_renderswap.c, g_disptab.h, and g_disptab_EXT.h will go away. The benefit is that new functions won't need to be added to a C file and a header file.
In the current code, a person must modify 5 source files (g_disptab_EXT.c, g_disptab_EXT.h, g_render.c, g_renderswap.c, and rensizetab.c) in order to add protocol for a new function. My proposed changes will reduce that number to 3 (dispatch_stubs.h, g_disptab_EXT.c, and rensizetab.c).
There is some hand editing in the patch to trim out some other stuff. A couple of the client-side library changes may no apply 100% cleanly. If there's a problem, please let me know.
I usually don't comment on design decisions (because of too limited knowledge on the matter), but I think it's a great idea. As I've just figured out, it IS a pain to implement glx stuff currently, so I think it can only get better ;-). I don't quite understand yet all the template stuff, especially how to handle the cases when the size of the command depends on the parameter (I'm not a fluent speaker of cpp ;-)), but I'm sure it's a good idea nevertheless (even though in general I'm not a friend of macro overuse).
I'm also not hugely familiar with the code, but this patch does seem to address some of the reasons I don't like going in there... I like the changes a lot...
Keith
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
