Hello,

I'm not sure if I am understanding the new GimpContext functionality correctly. I had hoped it would resolve issues that my Gimp Perl script has with certain non-thread-safe resources when multiple instances of the script are running concurrently. For example one instance changing the foreground color that another instance is using to render text. It happens infrequently but when I run multiple versions of a script with code like the following I still see occasional images being rendered with "incorrect" colors:

Gimp::init; my $img = gimp_image_new(300, 200, 0); gimp_context_push();
gimp_context_set_background([60, 108, 222]);

gimp_context_set_foreground([255,255,255]); my $text_layer1A = gimp_text_fontname($img,-1,0,0,"The Quick Brown Fox", 0, 0, 14, 0, "Arial");
gimp_context_set_foreground([0,0,0]); my $text_layer1B = gimp_text_fontname($img,-1,5,5,"Jumped Over the Lazy Dog", 0, 0, 14, 0, "URW Gothic L");

gimp_context_set_foreground([237,16,16]); my $text_layer2A = gimp_text_fontname($img,-1,0,20,"The Quick Brown Fox", 0, 0, 14, 0, "Arial");
gimp_context_set_foreground([0,0,0]); my $text_layer2B = gimp_text_fontname($img,-1,5,25,"Jumped Over the Lazy Dog", 0, 0, 14, 0, "URW Gothic L");

... code to save image ...

gimp_context_pop();

Gimp::end;

Is there anything that takes place behind the scenes that makes sure that each script is running in its own context? Or does the call to gimp_text_fontname simply use the latest context added to the stack, allowing for something like script x switching to look at a context pushed by script y while in the middle of executing calls to gimp_text_fontname? I guess I'm looking for something more like:

my $context = gimp_create_context(); $context->set_foreground([255,255,255]); # this call uses the context's foreground color gimp_text_fontname($img,-1,0,0,"The Quick Brown Fox", 0, 0, 14, 0, "Arial");
$context->delete();

I can see how push and pop would make sense for a plugin, but wonder if there's an alternate way for batch image scripting to make use of it.

Thanks in advance, Jared

_________

Sven-

I've been running my Gimp Perl script entirely as a single cgi communicating to Gimp through the perl-server without having registered any of the code. I think from your response that the portion of the script that sets the color, does the text rendering and pushes the gimpcontext needs to be executed within an individual Gimp procedure call which means I'll have to register at least that portion of it. Running it all as a cgi doesn't appear to "magically" make use of a script-only context, and so it was probably still using the user context. Let me know if I'm offbase on this.

Thanks, Jared

-----Original Message-----
From: Sven Neumann [mailto:sven@gimp.org] Sent: Friday, January 21, 2005 12:15 PM To: Jared Whiting
Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GimpContext and Gimp Perl's non-thread safe resources

Hi,

"Jared Whiting" writes:

Is there anything that takes place behind the scenes that makes sure that each script is running in its own context?

Scripts and plug-ins are by default run in the user context. Changing this would have broken backward compatibility so we had to choose the API where plug-ins and scripts have to push their own context if they want to run in their own context.

Or does the call to gimp_text_fontname simply use the latest context added to the stack, allowing for something like script x switching to look at a context pushed by script y while in the middle of executing calls to gimp_text_fontname?

The context stack is local to the current procedure. So if your script is executed in it's own procedure call and pushes a context, then that context is local to that script and can not be accessed by anyone else. Basically my answer boils down to: I don't believe that your scripts are misbehaving the way you described.

Sven