
<html><head></head><body>Right. This uses single void pointers, which is different but about as bad as vaearh and multiplexing for no reasons.<br><br><div class="gmail_quote">Le 22 janvier 2019 09:47:40 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">On 21/01/2019 18:41, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le maanantaina 21. tammikuuta 2019, 19.15.51 EET Rémi Denis-Courmont a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Le maanantaina 21. tammikuuta 2019, 18.38.43 EET Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">This is another variant of the same patches. This time there's only one<br>callback and the different calls are passed via control "messages" which<br>all have an input pointer and an output pointer (unused most of the time).<br></blockquote>This is even worse than the previous version IMO. Zero type safety. Awful.<br></blockquote> Besides binding writers do not like varags callbacks. So they should only be<br> used when actually justified by the use case. That is to say when the argument<br> list is actually variable such as printf/scanf/D-Bus.<br><br> It took me more than a decade to understand how vararg actually works, and<br> most C programmers still don't understand, though many think they do. So when<br> there are no actual reasons to use them, I don't want to use them.<br></blockquote><br>Good, I don't use varargs in these patches. There's an input parameter <br>and an output parameter, plus a return value.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Also this is again multiplexing, albeit at a different layer than the previous<br> version. I can see why you may need multiplexed function calls on context<br> boundaries such as system calls, IPC, network/RPC, or binary compatibility.<br> But I really don't see why you need multiplexing here.<br><br> As Thomas already noted in the previous thread, you could just add a new<br> function with whatever suitable and typed parameter(s) and/or callback(s).<br></blockquote><br>The general idea is that all those APIs work mostly the same <br>(init/destroy/setup output/swap) the rest is engine details. So it <br>sounds reasonable to have a least a common part.<br><br>BTW, it seems make/release current could replace the start/end rendering <br>needed in D3D as well. Unlike with OpenGL which uses it anytime the <br>context it used, it would only be called during rendering there. Making <br>the API even more generic.<br><br>The main differences remaining: init returns a shared context in D3D and <br>get_proc_address does nothing for D3D.<br><br>Not knowing Vulkan or Metal (which will slowly deprecate OpenGL) I can't <br>tell if anything else is needed.<hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>