So basically, I can't count on any of the interface improvements made in 2.6. "Great." I can always use wrappers for any kind of 3rd, 4th, 5th interface, but that would still mean keeping around old code, except maybe in its own module. Not to mention now I'd even have to make sure the "glue" logic also works. So thanks, but no. In this case I'll rather continue what I was doing sticking to 2.5-style, and devise
*one* new interface for Avisynth+ in the future, when the more important stuff are out of the way, and I can make sure that it will finally be alright. I am not in the mood of maintaining 4+ (redundant!) interfaces, and I don't think I ever will be. But to avoid misunderstandings, plugins should of course still use the 2.6 header. There is currently nothing better than that, as it is most feature complete, and does not suffer from the "baked code syndrome".
Quote:
Originally Posted by SEt
... General refcounting is done by scheduler based on 2, wrapper can do additional refs in response to 2.5 frame refs, but I guess it won't be used much.
|
Refcounting is nice and I would want to use it myself, but I really think I can't because of 2.5 baked code. You can supply the cleanup logic in the users of the frame classes instead of in the frame class, sure, so you could think that might work as long as the core always has the last reference to any frame, instead of the filters. The problem is, how will you know when the refcount reaches zero? The baked-in code won't tell you, so you are left with the choice of either periodic scanning, or with the choice of scanning only when needed, for example on out of memory, which is what current Avisynth does.
You say that we can do refcounting our own way however we want, and provide a wrapper for 2.5 plugins. That means we still have to duplicate the extremely complex old-style Avisynth caching, except in a wrapper, but in addition we must also develop and maintain a second caching system, the primary one?! This is just not worth it, because the old cache basically works. Yes it is way too complex for what it does. Yes it eats memory. But it works and it is not a performance bottleneck. So what reason is there to develop a completely new one if we still have to continue living with all the drawbacks of the current cache, except in a wrapper?