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)
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 <alexiade...@gmail.com> wrote:
> On Sun, Oct 4, 2009 at 4:19 PM, Vio <zaza...@gmail.com> 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