Thank you for the detailed explanation! It all makes sense.
To answer your question in parentheses - yes, displayed windows are run as separate processes, due to Qt requirements. All commands to draw, save, etc. are sent as commands to the displayed window process through a "pipe". So once the command to save the image is put into the "pipe", the main PyFerret process continues on. I can add code so the main PyFerret process waits for a reply from the displayed window process when saving an image. (I need to add code to wait for a reply to support the Ferret "where" command.)
I would think that to wait would be a good thing to do. Because we are talking about the interactive use of pyferret, the benefits of not waiting are probably marginal, but I'm not 100% sure. Without the wait, you get the "yes?" prompt and can type the next command right away . . . is this a very useful property in practice? If the answer is yes, we want to keep it. In that case, perhaps the FRAME command needs a "WAIT" qualifier. . . .
On the other hand, this introduces an inconsistency: FRAME is executed in the background but all other commands are executed in the foreground (using the shell-programming terminology) . . . .
Note that plots/windows that are not displayed (using the "-nodisplay" command-line option) are *not* separate processes. So using the "-nodisplay" option will also solve this problem, and create the images much faster. Of course, the plots will not be displayed as they are being made, but if you are just running a set of routine scripts to produce image files that you want to look at, this might be all you need.
That is useful information indeed. Thank you. I still run my scripts often in the interactive mode, to check the results by eye. When I make a set of similar plots (for animation, for example), I do use -nodisplay.
Regards,
Ryo