Thus spoke Marc Lehmann
> >    script_fu_old_photo($drawable, 0, 1, 1, 1, 0);
> Ah, now it's clear: script_fu_old_photo _destroys_ the layer that is
> passed in. Using the drawable after that was a bug in your (original) code
> (this is a very common bug).

True.  Still, I fixed that bug and still needed a delay to prevent
crashing.  And the delay had to be at least 2 seconds - 1 second delays
caused strange results.

> The problem seems to be that old_photo calls flatten, and this might
> change a lot of internal structures. the right fix would be to make
> old-photo return the newly created layer/image/whatever, but AFAIK
> script-fu is unable to return anything to the caller (scirpt-fu was never
> designed to be called from the outside, obviously).

This would be better, but it still doesn't account for what I see happen -
which is the second plug-in getting called before the first has finished.

> This is highly unlikely. the current set of perl plug-ins call a lot of
> other plug-ins (including pelr ones) without a problem. I am quite certain
> it's either an uncommon operation or yet another script-fu-breakage, for
> example, script-fu is the only plug-in that stays in memory all the time,
> even if not used, and uses temporary pdb functions instead of normally
> registered calls (that's why it's so slow on startup). This could be the
> key...

I tried this test with perl-fu and C plug-in calls but couldn't reproduce it.
It may be limited to calls to Script-Fu plug-ins.  I'm not positive of this
because few of the perl-fu and C plug-ins 1) take very long to process *and*
2) generate additional layers in the manner of Old Photo.  

In any case, the problem is pretty consistant with Script-Fu scripts.  I
tried a number of them.
Michael J. Hammel           |
The Graphics Muse           |  If ignorance is bliss, why aren't more 
[EMAIL PROTECTED]  |  people happy? 

Reply via email to