RE: [Gimp-developer] Gimp_image_delete and adding text layers
top isn't actually a very accurate way of profiling memory usage. The numbers you have shown so far can easily be explained by memory fragmentation and the fact that glibc allocates memory in pools. Smaller memory fragments are not returned to the operating system but are being kept for reuse in the application. Please run your script a lot more often and see if there's a significant increase in memory. Sven Jared Whiting [EMAIL PROTECTED] wrote: This script gets run 5000 times in a loop, and it's the only script accessing the gimp instance. ...I'm not sure how significant the increase is as I have to run the script quite a bit, but this is what I see after running several loops and using top after each loop: Start up: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17632 7448 13m S 0.0 1.4 0:01.14 gimp Loop 1: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21088 11m 13m S 0.0 2.2 11:45.59 gimp Loop 2: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25544 14m 13m S 0.0 2.9 23:28.40 gimp Loop 3: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27796 17m 13m S 0.0 3.5 35:11.54 gimp Loop 4: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31408 21m 13m S 0.0 4.2 46:54.84 gimp Loop 5: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 35220 24m 13m S 0.0 4.8 58:35.12 gimp Loop 6: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 38108 27m 13m S 0.0 5.5 70:11.92 gimp Loop 7: VIRT RES SHR S %CPU %MEM TIME+ COMMAND 42292 31m 13m S 0.0 6.2 81:51.41 gimp Thanks, Jared Is there any more information I can provide regarding my test script and the memory increase I observe with GIMP? Following your advice I ran my script more often, but I'm not sure if my response was what you were looking for. If I run a script that creates a new image with six text layers in a loop it results in about a 3000k increase in the amount of memory the GIMP process is holding on to for each 5000 times the script gets executed (as observed using top). There is only a single instance of the script being executed at any time. This behavior is similar to what I have observed in our more complicated script we use where small but permanent memory increases occur over time. I am open to the idea that there is no memory leak and that it's a problem with my script or that I'm providing unreliable/inadequate info regarding the issue so let me know if that's still the case. I mainly am looking for enough insight so I don't have to rely on having to restart GIMP for our image generation scripts unless it's absolutely necessary. Thanks, Jared ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Gimp_image_delete and adding text layers
top isn't actually a very accurate way of profiling memory usage. The numbers you have shown so far can easily be explained by memory fragmentation and the fact that glibc allocates memory in pools. Smaller memory fragments are not returned to the operating system but are being kept for reuse in the application. Please run your script a lot more often and see if there's a significant increase in memory. Sven I have a test script that does the following: Gimp::init; my $img = gimp_image_new(300, 200, 0); $img-gimp_image_undo_disable; my $layer = gimp_layer_new($img, 300,200,RGB, Layer 2, 100, NORMAL_MODE); gimp_image_add_layer($img, $layer, -1); my $text_layer = gimp_text_fontname($img,-1,0,0,, 0, 0, 14, 0, Arial Bold); gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER); my $text_layer2 = gimp_text_fontname($img,-1,0,10,2, 0, 0, 14, 0, Arial Bold); gimp_image_merge_down($img, $text_layer2, CLIP_TO_BOTTOM_LAYER); my $text_layer3 = gimp_text_fontname($img,-1,0,20,3, 0, 0, 14, 0, Arial Bold); gimp_image_merge_down($img, $text_layer3, CLIP_TO_BOTTOM_LAYER); my $text_layer4 = gimp_text_fontname($img,-1,0,30,44, 0, 0, 14, 0, Arial Bold); gimp_image_merge_down($img, $text_layer4, CLIP_TO_BOTTOM_LAYER); my $text_layer5 = gimp_text_fontname($img,-1,0,40,555, 0, 0, 14, 0, Arial Bold); gimp_image_merge_down($img, $text_layer5, CLIP_TO_BOTTOM_LAYER); my $text_layer6 = gimp_text_fontname($img,-1,0,50,6, 0, 0, 14, 0, Arial Bold); gimp_image_merge_down($img, $text_layer6, CLIP_TO_BOTTOM_LAYER); $img-gimp_image_undo_enable; gimp_image_delete($img); Gimp::end; This script gets run 5000 times in a loop, and it's the only script accessing the gimp instance. I see no change in the perl-server and script fu processes, but I do see an increase for gimp. I'm not sure how significant the increase is as I have to run the script quite a bit, but this is what I see after running several loops and using top after each loop: Start up: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 17632 7448 13m S 0.0 1.4 0:01.14 gimp Loop 1: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 21088 11m 13m S 0.0 2.2 11:45.59 gimp Loop 2: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 25544 14m 13m S 0.0 2.9 23:28.40 gimp Loop 3: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 27796 17m 13m S 0.0 3.5 35:11.54 gimp Loop 4: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 31408 21m 13m S 0.0 4.2 46:54.84 gimp Loop 5: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 35220 24m 13m S 0.0 4.8 58:35.12 gimp Loop 6: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 38108 27m 13m S 0.0 5.5 70:11.92 gimp Loop 7: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 42292 31m 13m S 0.0 6.2 81:51.41 gimp Thanks, Jared ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Gimp_image_delete and adding text layers
How much memory increase do you see per image? Can you run this script a couple of times and show us memory usage before and after? Sven When I first start up GIMP: /usr/bin/gimp -d -i -c --batch '(extension-perl-server 1 0 0 )' I see the following using top (script-fu and Perl-Server processes never change so I'm not including those): VIRT RES SHR S %CPU %MEMTIME+ COMMAND 18440 7444 13m S 0.0 1.4 0:01.07 gimp Then I execute the code shown at the end of this message, and I see the following: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 18648 8056 13m S 0.0 1.6 0:01.12 gimp Within the code I add an additional text layer and use gimp_merge_down, and see no change. I add seven text layers and still no change (I had originally thought adding a new text layer ALWAYS results in more memory being taken but this is not the case, so my initial description of the problem is misleading.) After running the script with the new text layers about 25 times in rapid succession I see the following: VIRT RES SHR S %CPU %MEMTIME+ COMMAND 18788 8196 13m S 0.0 1.6 0:06.23 gimp This behavior occurs with this sample pretty consistently. Not a huge increase, but the cgi I'm using in production does a lot more than this and can be generating a few thousand images in one day. Thanks, Jared ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Gimp_image_delete and adding text layers
Are any of these concurrently, and if so how many; could this make a difference? ~Mike In production there can definitely be concurrent image generation, which might be playing a role in the issue I'm having there with increased memory. With the test code though I'm just running the script many times in sequence. Thanks, Jared ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] Gimp_image_delete and adding text layers
... meant to write GIMP 2.2.8 -Original Message- From: Sven Neumann [mailto:[EMAIL PROTECTED] On Behalf Of Sven Neumann Sent: Tuesday, August 16, 2005 2:09 PM To: Jared Whiting Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] Gimp_image_delete and adding text layers Hi, Jared Whiting [EMAIL PROTECTED] writes: I am currently using GIMP 2.8 for GNU/Linux, There is no such GIMP version (yet). What version are you really using? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp_image_delete and adding text layers
I am currently using GIMP 2.8 for GNU/Linux, Gimp Perl 2.0 with Pango 1.10. I'm using a cgi to dynamically generate images through the Perl Server and in general it works very well. Currently we do need to restart the GIMP instance and perl server on the machine because in the process of creating images the GIMP keeps holding on to more and more memory. As an example, I can run the following script: use strict; use lib qw(/www/lib/perl); use Gimp qw(:auto); Gimp::init; my $img = gimp_image_new(300, 200, 0); $img-gimp_image_undo_disable; my $layer = gimp_layer_new($img, 300,200,RGB, Layer 1, 100, NORMAL_MODE); gimp_image_add_layer($img, $layer, -1); my $text_layer = gimp_text_fontname($img,-1,0,0,, 0, 0, 14, 0, Arial Bold); gimp_image_merge_down($img, $text_layer, CLIP_TO_BOTTOM_LAYER); $img-gimp_image_undo_enable; gimp_image_delete($img); Gimp::end; If I add a new text layer in the script above and rerun it, I see that the GIMP instance grabs on to more memory and holds on to it permanently. Deleting the image and disabling undo do not result in the GIMP releasing memory for the new layer it created. I would prefer not having to restart GIMP and its perl server so I'm looking to see if there is anything else I can do to force it to free up memory. Thanks, Jared Jared WhitingMyers Internet, Inc. Sr. Web Developerhttp://www.myers.com (408) 428-9960 Taking Your Business To The Next Level ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] GimpContext and Gimp Perl's non-thread safe resources
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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpContext and Gimp Perl's non-thread safe resources
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 Jared WhitingMyers Internet, Inc. Senior Developerhttp://www.myers.com (408) 428-9960 Taking Your Business To The Next Level ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Debugging gimp_text_fontname error with non-ascii
I had filed a bug (http://bugzilla.gnome.org/show_bug.cgi?id=157709) about this for gimp-perl a couple months ago and hadn't heard back, but I'm looking for some advice on how to further debug this issue as it may not even be gimp-perl specific. When I call the following pdb function with any non-ascii character in my perl script: my $text_layer = gimp_text_fontname($img,-1,0,0,test string รถ, 0, TRUE, 14, 0, Arial); The function simply fails, and returns the following error gimp_text_fontname: procedural database execution failed at ... With no more useful information. Displaying the stack trace doesn't give me any additional useful information as well. gimp_text_get_extents_fontname gives a similar error with a non-ascii character, but another pdb function I found that generates text - script_fu_newsprint_text actually seems to succeed as it returns no error. Incidentally, I've experimented with different fonts and characters, and can only comment that these characters were not causing an error with Gimp 1.2. (I've tested this on Gimp 2.0.5, 2.2 for GNU/Linux, Gimp Perl 2.0 and Pango 1.6.) Any advice on what to look at next would be appreciated. Thanks, Jared Jared WhitingMyers Internet, Inc. Senior Developerhttp://www.myers.com (408) 428-9960 Taking Your Business To The Next Level ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
