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

[Steve Lhomme]

I don't understand the "multiplexing" word in this context. The API 
forces the use of one particular API at a time. And that's actually a 
point in favor of using one single entry point for the surface API.

Unlike the HWND/XWindow/NSObject/etc this API can be used on one OS to 
call different engines.

As for the strong typing, it will always be suboptimal because we can't 
use the real types (IDirect3DDevice9/ID3D11DeviceContext) just like we 
don't use HWND or NSObject explicitly.

On 22/01/2019 08:57, Rémi Denis-Courmont wrote:
> 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é.
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel