On GIMP and CORBA

[Felix Bellaby <felix pooh u-net com>]

Lauri Alanko wrote:
> One cannot do a global "change pointers to object references"
> translation in the core code, for that matter. I think that a sensible
> compromise is to have separate wrappers to most of the high level
> operations (such as on images and layers), which require and check
> that all its object arguments are local to its process, then retrieves
> the implementations (the actual object pointer), and passes those to
> the actual routines. Currently, only the gimp core actually implements
> images and layers, so this is not much of a restriction.

I believe that the stub functions which marshall calls in efficient
CORBA implementations check whether the object's implementation is
resident in their own address space before doing any marshalling.
(Objects obviously have to maintain references to where their
implementations reside). When the implementation is in the same
address space there is no need to marshall and demarshall the
code. Indeed, the design of the POA in CORBA 2.2 means that there is
no need to create a new stack frame: the implementation code can
simply take over and return from the frame. This means that
invocations on CORBA objects in the local address space are only very
slightly slower than direct C function calls :-).

The Fresco toolkit is able to implement its WIDGETS entirely in CORBA 
without unacceptable inefficiency (it does cheat a bit by using a
version of CORBA that is unable to make network connections!!)

> Which brings to another point: mass data transfer. Extensions,
> especially filter plug-ins, require the moving of lots of image data
> back and forth. Currently, this is relatively fast, because shmem is
> used. Although CORBA by default supplies only a socket-based
> communication medium, I think we can either use shmem by hand, or
> (preferably) write a shmem-based GIOP implementation for ORBit.
>
> Alternatively, the extension could make a local copy of the entire
> image it operates upon and use the gimp operations locally (from a
> lib) on it.
>
> The place where data transfer latency is absolutely essential is in
> brushes, because these have to be completely interactive. The idea is
> to make these distributed as well. I'm not sure whether it's possible,
> even with shmem, to achieve sufficient transfer speeds between address
> spaces. There has also been an idea of dynlinking the brushes to the
> core (here "core" probably meaning the process implementing the
> GUI). This wouldn't be a very portable solution, (though in systems
> that don't provide dlopen, this would simply mean the set of brushes
> is fixed at compile time, not a horrible restriction). Also, I don't
> know how this would interface with CORBA. Brushes are supposed to be
> scriptable, too, so they have to have some sort of external
> interface...

CORBA supports the dynamic linking of implementation code into the
address space of running executables as part of the standard. Systems
without dlopen do not fully support CORBA. I suppose you could add
memory sharing into the stubs and skeletons on those systems.

As to how much code you would need to write to implement all this, I
would say less than you think. You already have mico available which
may be slow and C++ (with a C wrapper!) but it provides you with an
interface repository in a daemon (or shared library)  and everything 
you need for starting extensions on demand using a daemon. ORBit should
have all this and more when it is finished.

The standard CORBA interface to the interface repository is very
simple and I have already got a GNOME compliant GtkCTree up and
running that displays its contents (at least the stuff the gimp user 
would want to see). I should have dynamic invocation of its procedures up
within a month. So do not worry about the CORBA stuff, the problems
will be in adapting the GIMP to use it :-).

Felix