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 fails. 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 to. 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. Rockwalrus
