Quote:
Originally Posted by SEt
2.6 interfaces are useless – they solved nothing while breaking binary compatibility, usage is very low. I'd say implement only 2.5 compatibility.
New interface obviously needs to be the only one and extensible. Btw, this implies that it must be C style and not the C++ hell like now. For exact design I'd say COM-like: great scalability and linking compatibility.
As for wrapper complexity – it greatly depends on which and how efficient you want it to support quirks of 2.5. Sure, maybe 2.5 plugin that formatted your hard drive would require total emulation to work correctly, but do we care? I suspect that quite simple wrapper + some special cases would be ok for most interesting plugins.
And FTY, caching is the main problem of Avisynth MT. Not threading hacks, not 32-bitness how quite a few people think. And it is performance bottleneck.
|
Well I'm rewriting caching and memory management from scratch anyway. Coz I agree that current cache doesn't lend itselft to MT naturally. In single-threaded mode though it didn't seem like a bottleneck, as it didn't even show up in profiling results.
I also agree that new interface needs to be C-style. My plans are to make it object oriented (as far as C allows), but keep objects totally opaque. An extremely thin C++ wrapper shipped as public include files will provide C++ binding, but it will only provide syntax sugar and some help in memory management thanks to destructors.