Ahh, the blessed holiday known as finals week has arrived. A wonderful
respite from that torture known as homework, when all the programming
projects and other assignments that one's professors have seen fit to
inflict upon their hapless and unsuspecting pupils have finally come to a
much welcomed end. Yes, a week of rejoicing heard from thousands of
voices, simultainously exclaiming their utter glee! What better time in
the life of a college student could there be?
Just as I promised, I have been studying how to implement tool plug-ins.
There is a basic tradeoff of stability verses speed and latency that has
to be evaluated. Current plug-ins run as a separate process, in a
separate address space, so that a buggy plug-in cannot cause the entire
gimp to crash. This is highly desirable because a user can run a new
plug-in with a high degree of confidence that they won't loose data if it
On the otherhand, there are issues of IPC bandwidth and latency that
arrise when out-of-process plug-ins are used. On a Linux machine with
shared memory enabled, these limitations are not a big deal for plug-ins.
This is true (to varying degrees) on other platforms as well. Most
machines running any modern Unix in most instances perform quite
acceptably under this system.
However, latency is far less tolerable in an interactive tool. While much
latency can be eliminated with a well designed caching/prefetching scheme,
the basic problem is transmitting the mouse events to the plug-in process
with minimal latency.
I've heard that it's possible to get X to deliver events to another
process, and I know that it is possible to get Windows to do so, but this
would involve a level of windowing system-specific coding that I don't
think is appropriate for the gimp codebase. Depending on such an unusual
feature also probably significantly decreases the flexiblity of the source
-- or in other words, limits the kinds of systems that Gimp can be ported
Some horrible kludge could also be dreamed up involving GTKPlugs. That
would move the windowing system dependance down to the GDK level, but
would also make things ineligant, and it would be difficult to get it to
work in all cases, especially with an unreliable plug-in.
So it seems that the best solution for tool plug-ins, slow as it might
seem, is to have the gimp process send the tool plug-in the events using
the same gimpwire protocol used for normal plug-ins. This also has the
advantage of allowing the maximum amount of code reuse possible. We may
very well want to expose event handlers to the PDB, but if so, some kind
of system needs to be designed so that the overhead of a pdb lookup is not
required for every event.
Which brings us to implementation on the gimp side. The obvious solution
is to write a stub tool object that knows how to communicate with the tool
plug-in. Whenever a tool plug-in registers itself at startup, the tool
plug-in, in the form of the stub, gets registered with the tool manager.
A better solution for stable tools is to have them loaded into the GIMP
process space. This is fairly trivial to do, thanks to GTypeModule.
Since it's not possible to know ahead of time whether a given plug-in will
be stable and whether a particular user would rather a certain plug-in be
faster, it seems best to make it so that tool plug-ins can work as either.
This simply requires that out-of-process tool plug-in modules be loaded by
a skeleton such as a (much improved) version of plugin-helper. Then a
user interface can be made such that the user can decide whether speed or
stability is prefered. This should be on an individual basis so that a
user can make commonly used tools fast, while making that one tool that
keeps crashing run in a separate space.
The only problem with this solution is that the api that in-process and
out-of-process components of the GIMP, while similar in nature, are
slightly different, especially in terms of the names of the functions
used. These differences will have to be reconciled, either by making the
functions have the same names, or by writing some kind of wrapper such
that they can be used by either.
Well, that is enough writing for tonight.
Gimp-developer mailing list