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

[Steve Lhomme]

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.