[vlc-devel] [PATCH 0/8 v4] surface rendering callbacks

[Rémi Denis-Courmont]

Right. This uses single void pointers, which is different but about as bad as vaearh and multiplexing for no reasons.

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

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190122/f0a8c684/attachment.html>