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

[Rémi Denis-Courmont]

This multiplexes different functions as different request IDs only to demultiplex them in a switch statement.

There are absolutely no reasons to do that here, at least none were provided.

And as already noted, I want to keep the familiar GL provider pattern for GL. The GL API should be obvious for somebody familiar with GL to use. That's far more relevant here than some hypothetical generalisation.

Le 22 janvier 2019 11:30:52 GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit :
>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
>
>_______________________________________________
>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/a12a7474/attachment.html>