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

Reply via email to