Well, I was hoping some of the COM experts would comment on that. If I understand it right you are avoiding writing some thunking routines for older interfaces, at the cost of an extra pointer access in every function. I'm not convinced it's a good trade-off, but I'd like to hear other opinions.
I might not exactly be an expert, but I don't like the extra work being done everywhere with the extra pointer. If writing the thunk functions is really so cumbersome, perhaps a macro for generating the thunk functions is in order.
I might not exactly be an expert, but I don't like the extra work being done everywhere with the extra pointer. If writing the thunk functions is really so cumbersome, perhaps a macro for generating the thunk functions is in order.
Well, I am currently rewriting the code with the thunks (should be sent in this evening if nothing breaks :-) ).
I will ask though to all people voting for thunks to review the (about) 100 thunks I had to write for this patch due to this decision and to check if all are correct according to MSDN definitions.
For me, to have a little speed loss (well, it's only one additionnal memory access) in all interfaces and a lot less complex code (ie a lot less functions) is better than having the latest interface at full speed but a much bigger (IMHO) speed loss for all old interfaces (for all thunks, you have at least one comparison, one pointer arithmetic and one function call if not more if you need to thunk more than one interface). Moreover (this is not the case here, but well) if ever interface X + 1 comes out, you need to rewrite a lot of your code (as you need to create thunks for all functions in X and rewrite the X + 1 functions with the new interface).
But well, as the decision was taken, we won't go back now (otherwise, I will have spent my last 10 hours of Wine hacking time for nothing).
Lionel
John K. Hohm wrote:
Well, I was hoping some of the COM experts would comment on that. If I understand it right you are avoiding writing some thunking routines for older interfaces, at the cost of an extra pointer access in every function. I'm not convinced it's a good trade-off, but I'd like to hear other opinions.
I might not exactly be an expert, but I don't like the extra work being done everywhere with the extra pointer. If writing the thunk functions is really so cumbersome, perhaps a macro for generating the thunk functions is in order.
The COM patch does not only aim to avoid generating thunks but also to remove the thunks that obfuscate the code and to make the code easier to understand. Indeed in the code they are just thunks and thunks + some conversions. And I think it can good to see the conversion code alone rather that lost in a bunch of useless thunks.
Maybe there are others ways to have a cleaner code (that makes intense use of multiple interfaces)...
Anyway, as Lionel pointed out, we will do without the patch. I hope his "revival" patch will be applied as soon as possible so real D3D development can start. :-)
Bye, Christian
-
Christian Costa -
John K. Hohm -
Lionel Ulmer