Frame types for AVS 3.0

[Bidoche]

design generic plugin interfaces that will allow plugins to remain through API changes

That would be the work of COM.
But for now I ain't the guy to tell you much about it.
Avisynth already uses COM (from vfw), but does not exposes itself as COM objects.

the best working cache implementation in 2.5 without breaking plugins

Arghhh...

I assume they will not be needed for plugin compilation!?!

As long as we don't use them in avisynth.h (for 2.5)
For 3.0 it doesn't matter, plugins will be linked throught COM.

For "AVI output" we are given a framebuffer by VFW, so we have to bitblit here anyway. I could however imagine that the image writer could use "specific pitch" images. Some way to create a new frame, where you can force pitch would be nice.

Can you be more descriptive.

I'd just like to know what the advantages are

Here a simple example: comparison of T * and (one of the possible replacement) boost::scoped_ptr.

scoped_ptr is a template class, ie its needs a class parameter to be fully qualified, the same way when you define a pointer you precise to which object it points.

You write it like it : scoped_ptr<T> pT; //T is the template parameter
where before you wrote: T * pT; //T was a parameter too

Before you had to explicitely initialize pT to 0 avoid garbage.
scoped_ptr has a default constructor who set itself to 0, so you don't have to care about that.
(Already one line less to write).

In destructor, you had to do : if (pT) delete pT; (or just delete if you know != 0)
scoped_ptr automatically deletes the owned object when it leaves the context.
That means you don't have to worry about deletion of the object in the destructor (or elsewhere) (one more line less).

But there is more, it makes it exception-safe :
If you construct an object with new, then call some code who throws an exception.
If you excepted the exception for some treatment, you catch it, do what must and go on.
If you excepted the exception but cannot handle it, you catch it, delete your pointer (otherwise it's leaked) and rethrow the exception. It works, but it's a costly solution (in developpement time).
If the exception caught you unaware, your pointer is leaked and there is nothing you can do about it. :/

On the contrary, with a scoped_ptr, no possible leak.
The scoped_ptr destructor (which delete the object) will be automatically called in the stack unwinding process.


Conclusion : Besides being safer and faster to use than a regular ptr, so why not use it.
Imagine there were no PVideoFrame and you had to use VideoFrame * and handle the AddRef/Release calls by yourselves. That's the same idea.

NB: scoped_ptr is only one of the possible smart ptr , who do not share ownership, there are others.

[Bidoche]

On a completely different subject, I suggest we add this method somewhere :

//paint a memory rectangle of given width, height, pitch
//with the values of its first line
//(pitch allowed negative to paint from bottom to top)
void RectanglePaint(BYTE * dstp, int width, int height, int pitch)
{
  BitBlit(dstp, pitch, dstp, pitch, width, height);
}

I have continued reading of source.cpp and this would be an appreciable factorisation for ColorBars, BlankClip (maybe others)