View Single Post
Old 9th July 2016, 11:14   #11  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,559
The MT issues I saw may simply be because I was using a class with thread affinity that cared from which thread it was being called. Without using such a class, then it might work just the same as with C++. Have to test more.

In terms of performance, often low performance doesn't come from lack of assembly code and raw execution speed, but rather from poor code structure due to a huge amount of unreadable code that piled up over time. On this point, C# wins major points. It allows for much better and simpler code structure that can be maintained a lot more easily.

I've done a lot of database applications, and the best practice for such application is to split the solution in 3 layers: UI, Business Logic and Data Access. In the same way, it would make sense to completely separate the plugin logic from the raw frame data operations. The plugin logic can be maintained and simplified in a C# project, while the raw calculations are being done in a separate layer. Such functions generally need a code splitter and several implementations: CPU, SSE2, AVX.

Separating the plugin logic from the raw operations also might be the easiest way to port the plugins to other platforms in the future. The plugin logic is cross-platform compatible, and all that needs to be rewritten is the assembly in the raw operations layer. Porting then becomes very easy. The only downside: it requires 2 DLLs instead of 1; plus AviFilterNet.dll.

That being said, the first person to develop a plugin with this may need to still fix a few bugs and/or implement a few missing features while using AvsFilterNet.
MysteryX is offline   Reply With Quote