You're right. Keeping a running Gimp daemon in memory would most certainly speed things up (for subsequent calls) I recall the python tutorial has some sample code on writing simple servers in python (so, the python code is already available, therefore I'd guess it's probably just a matter of importing it into the Gimp-python plugin - hence no need to do much/any low-level socket programming. I'm running my devel code (apache+mod_py+Gimp) on a tiny web-book (acer's aspire one) so I'd guess better performance would be achieved de-facto by simply using better hardware (I mean, in a production environment). (and re-writing all this in C would obviously win the 100m hurdles, but that's overkill for me, for now, I'll be happy with working python code) vio PS. Hey, nice last name :) Sounds like You must get a lot of action at Halloween... On Sun, Oct 4, 2009 at 12:02 PM, Alexia Death <alexiadeath@xxxxxxxxx> wrote: > On Sun, Oct 4, 2009 at 4:19 PM, Vio <zazavio@xxxxxxxxx> wrote: >> Invoking GIMP from mod_python works Ok, but it is quite slow. >> 1 round-trip request - from the client page requesting the Gimp stuff >> until the server gets back to the client with the response page >> is quite long - about 10-15 sec - and most (ALL?) of the time is spent >> on the Gimp side, NOT the apache/mod_py side. >> So obviously this is not a speed demon, as Gimp was not >> designed to serve web requests. But speed problem aside, >> it does work. ... it just needs 'veeery' patient users :) > > I suspect part of the speed problem is that gimp is started and loaded > at each call. a running gimp process is capable of taking over without > a new process at least for opening images, but I don't know if you can > do this for scripts. You might get better times if you write a plug-in > that listens on a socket and executes received pdb calls. _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
