>>>>> "Einar" == Einar Ryeng <[EMAIL PROTECTED]> writes: >> I haven't thought about this at all. Btu I think we should look into >> how hard it would be to do plugins in a seperate process. Maybe a >> process for GUI and main application and a process for ALL plugins..?
Einar> That should be easy enough, I guess. But processes are cheap in Einar> posix, so I don't see any need to reuse them. This is RAW processing, folks! Processes may be cheap or they may be expensive, but whatever's the case, the sheer amount of computation done in conjunction with manipulating an image is going to dramatically overshadow any overhead of creating a thread. At any rate I think that a good architecture is worth significantly more than a performance hit. Einar> But that was just an idea anyway. As long as network transparency Einar> is not a requirement, shared memory (without any ORBish Einar> mechanism) is probably easier. Isn't network transparency irrelevant? Sure, if network transparency is offered for free, that would open up for some interesting projects to be done by computer science students with a combined interest in distributed computing and image manipulation, but for everyone else, I don't see that there's anything to be gained. I can't think of a single case where it's a practical advantage to do such processing over a network, which is not to say that no such cases exist. Einar> I just tend like clean interface separations when there is Einar> actually a real possibility to have them ;) I think that this is an important point, and I have a few ideas about this that might be a bit extreme, but I offer them anyway. A plugin must basically consist of two things: 1) a configuration part with a GUI component that outputs the settings of the plugin, most likely just to the XML file, and 2) a processing part whose input is said configuration along with the image before processing and whose output is the image after processing. So my conclusion is that we could just keep the two parts completely seperate and use the most basic UNIX building block for IPC: pipes. This would simply require that a protocol be agreed upon, e.g. first the configuration file is passed, then the image as a 16 bit TIFF. Then the processing part of plugins would be trivial to write (and, yes, even to make network transparent :-)), and making wrappers for scripting languages would be as simple as providing a method for parsing XML and decoding TIFF. This approach also lends itself excellently to parallel processing. Moreover, it would also make it trivial to do stuff like adding the same output plugin twice in the processing chain to save a file as a full-quality TIFF as well as a reduced size/quality JPEG for previewing purposes. Einar> The easiest way is to let each plugin make dialogs for whatever Einar> it wants to do. I guess that is the best way to do it for Einar> import/export plugins. For filters I get a feeling that the best Einar> way to incorporate them into the GUI would be to give each plugin Einar> an expander in the tools list. That way, they actually behave Einar> like an integrated part of the program and you just get a "Noise Einar> reuction" expander with a "level" slider beneath the sharpening Einar> tool. This must be done in the same process that runs the GUI, so Einar> the .so file approach would likely be the way of least Einar> resistance. I quite agree that what interface is concerned, plugins should integrate into Rawstudio like the current tools do today. As for the rest of your post, Einar, it is very C-centric, and I think that we should beware of painting ourselves into that corner. All in all, this discussion is focused rather narrowly on implementation details (we nerds do tend to go there as fast as we can, don't we? :-)), but I think that it's a bit too early for that yet. I think that we first need to discuss interface in a more abstract manner, even philosophy of interface. There are some questions that spring to mind that might be useful to debate: 1) Should the configuration and processing parts of a plugin be split? 2) Should Rawstudio be considered a library that plugins can call? 3) Should plugins be considered libraries that Rawstudio can call? 4) Alternatively, should Rawstudio primarily be considered a GUI that organises a daisy-chain of processing modules (plugins)? 5) How should plugins that enter at different points in the 'processing stream' be treated differently? I'm sure that there are plenty of other questions that need to be raised, but these are the ones that immediately sprang to mind. Martin _______________________________________________ Rawstudio-dev mailing list [email protected] http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
