[Bf-committers] VSE Strip-Wise Rendering

[Dan Eicher]

On Fri, Oct 1, 2010 at 3:19 AM, Peter Schlaile <peter at schlaile.de> wrote:

> Hi,
>
> > I have libplugin (http://libplugin.sourceforge.net/intro.html) working
> in
> > blender. Well, extensions and join-points at least, still haven't ported
> > over the (semi-)current plugin systems to use it. When I say 'working' I
> > mean on linux building with cmake BTW, probably be a chore to get windows
> > going since it brings a couple extra libs into blenderdom.
>
> in fact, it doesn't look like the way, a plugin system for blender should
> work IMHO. We are not aiming at *replacing* core functionality, but
> providing a clean way, to add certain types of filters / effect tracks
> etc.
>
> It's really just a wrapper around the .so/.dll symbol fetching functions
plus some 'object abstraction' at its core, the libffi stuff is extra icing
on the cake IMO. If someone ever *wanted* to replace built-in stuff (like
the 3dview axis widget in my current tests that someone actually requested
be replaceable) then you can with a simple change in blender's source.

Adding different 'types' of plugins is as simple as filling in a struct and
calling a register function -- they just aren't built in to the core library
since that's most likely application specific and you can have your plugin
types be plugins themselves.

Ideally Blender shouldn't even know or care if the
seq_effect/texture/shader/silly_3dview_widget/etc is compiled in or loaded
from an external lib which is what I'm aiming for with this project.

And: in comparising to my proposal, it doesn't solve all the interesting
> things (API version control, symbol dependencies), adds additional
> complexity through XML files and seems to be centered on Linux.
>
> You say 'centered on Linux' like that's a bad thing...

It has {application,plugin,libplugin} version control and symbol
dependencies (as I understand them). Admittedly internal version control
needs some love but the basics are there and plugin version control is just
a placeholder at this point IIRC but application version control is simply a
callback function that can do anything you want

Other than libltdl (which is easily replaceable, it didn't start out using
it) the other extra libs (libxml & libffi) I believe are already both python
deps.

Anyway you look at it there's going to be extra complexity either through
opening every .so/.dll in a filesystem tree and inspecting the symbols,
executing every python script or parsing every xml file if you want
auto-loading of plugins at startup.

And then you have to come up with a way to keep track of what libs export
what symbols, what libs belong to what plugins, extensions and join-points,
different types (seq, texture, etc) of plugin loading methods, what blender
brings to the table (register functions and whatnot) and wrap is all up in a
python and/or C api.

Sounds like a *lot* of work to me.

Plus there's the "recursively importing from the {user,system,comandline}
plugins folder at startup works right now" argument.

But that's just my first impression, feel free to proof me wrong :)
>
> I looked at pretty much every plugin system on the internets and this is
the best/most full featured out there that's not a digital sledgehammer. The
guy who wrote this really has his act together, compsci phd and all that.

Pretty sure the original lib is abandoned so I forked it to make it work
with recent libffi, get rid of gcc hash table dependency, the afore
mentioned libltdl changes and did a little refactoring of headers/function
names to avoid 'namespace' clashes...that bug was a bit tricky to track
down.

Currently working on getting the (lame ass) msvc export symbol changes made
so it can work in a non-gcc compiled .exe.

If there are serious objections the xml stuff can be #ifdef'd (which I'll
probably do anyway now that I think about it) and anything that is missing
can be added since the intent is to have this live in /extern as a
semi-independent lib.

Dan