Re: [Gimp-developer] Big Fat Piggy Gimp
Layer deletes are a little funky: they don't get deleted when they are removed from the layer list, since they get pushed on the undo stack. They get deleted when the undo information is freed, ie when it expires or when it is on the redo stack and an new action is pushed on the undo stack, thus blowing the redo stack. Messing with reference counts might be an attempt to achieve this; I don't know. It's worth checking, if only to discount it. I also think such messing is really ugly, and as we're discovering, totally unmaintainable. Fixing a leak of this magnitude is definitely cause for another stable release, I think. It goes without saying that it should be widely and thoroughly tested, possibly by a 1.2.2alpha pre-release snapshot or something. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Big Fat Piggy Gimp
Hi, Garry R. Osgood [EMAIL PROTECTED] writes: What bemuses me is this sink-but-not-really-sink policy for layers and channels that prevails around 1.2.1 tile mismanagement, and which finds partial realization in layer_ref(). [layer.c-CVS-1.72.2.1 gimp-1-2] This brief little snippet explicitly increments the object reference count of layers (gtk_object_ref()) before invoking gtk_object_sink(). After this intrusion into private GTK object management has been pulled off, we are left with a special layer that is not floating, but not quite sunk either (it has a positive reference count). calling gtk_object_ref(); gtk_object_sink(); is definitely correct and not strange at all. It is what containers that take ownership of an object are supposed to do. I'm not saying that everything is fine (it apparantly is not), but I wouldn't say we are messing with the GTK+ object system here. The strange manipulations of layer_ref() is limited to gimp_image_add_layer(), where it is applied on layers that are being addedto the list in GimpImage::layers Yep. GimpImage::layers is a container and thus sinks the floating object after referencing it to make clear that this object hads found its home and now belongs to the container. Any attempt to delete it using layer_delete() will fail now since the layer is associated to an image and bad things will happen if you delete it without removing it from the container. This is what the comment in layer.c (around line 590) tries to make clear. The problem is most probably located in the undo code. If you remove a layer from an image the image should drop its reference to it. To avoid that it gets deleted and thus can never be readded by an Undo operation the undo stack should reference the layer before removing it from the image. The undo system then has to take care of dropping its reference as soon as the relevant undo step is removed from the stack. I guess this is where the real problem is located. Happy Gimp. The motivation for this layer_ref() trickery appears to date to Feb - August 1998 (Gimp 0.99.x) when Scott Goehring first Objectified Gimp drawables. GTK was in flux then as well, and I surmise (reading mail from the period is not clear on this) that GTK object referencing was a bit queer anyway. If so, is layer_ref() (and its effects) a kludge that has outlived its usefulness? Quite frankly, I get better memory management when I disable this non-standard reference manipulation and leave GTK object management internals undisturbed. You will get very bad effects if someone calls layer_delete() on a layer that has been added to an image and on the other hand you want to allow to delete layers that are not part of an image. This situation is exactly why the concept of floating objects was introduced to GTK+ and I think we are using it the way it was designed for. Personally, I think this is a must-fix that justifies a 1.2.2 release, Yes, we should definitely fix this. I'll try to have a closer look later today. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [gimp-developer] UI Stuff
Martijn Weisbeek writes: The current release-version BTW is not a good advertisement. Well, luckily I don't have to worry about market share... There's been an error while compiling somehow (which required some patches) and those patches have not been implemented in the download. Actually, I wouldn't mind at all if there appeared a competing installer of GIMP for Windows, with more frequent releases. All the pieces are available. (There is an alternative installer package targetted at Japanese users, BTW.) I would have built a new one by now, but unfortunately (and unexpectedly) lost Internet access from home when moving in April... (Oh well, so I have spent more time with my family, books, and outdoors instead.) --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-Perl, Perl-Fu, Mandrake 8.0
On Sat, 09 Jun 2001, Marc Lehmann wrote: it seems that mandrake-8.0 comes with a broken gimp-perl, but I am not sure what is atcually the culript. the wrokaround (compiling/installing it yourself) has worked fine so far. It seems that the whole Gimp package in Mandrake 8.0 behaves strangely (not only Gimp-Perl). I am still not 100% sure that it is Mandrake's fault, but I would like to get a confirmation of that because it would help answering future bug reports. Specifically, I would like to get some feedback from people who are running Mandrake 8.0 and using the Gimp package delivered with the distribution, as well as from those who recompiled from the sources. It would be nice if you could have a look at bugs #55398 and #55735, and see if you are affected or not: http://bugzilla.gnome.org/show_bug.cgi?id=55398 http://bugzilla.gnome.org/show_bug.cgi?id=55735 Of course, I would also be interested in knowing if any other OS or Linux distribution is affected by the problems described in these bug reports. But so far, this has only been reported by Mandrake users. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Big Fat Piggy Gimp
Hi, Big, Fat Piggy Gimp Fans,
here's a very small patch that should fix our huge leak:
Index: app/gimpimage.c
===
RCS file: /cvs/gnome/gimp/app/Attic/gimpimage.c,v
retrieving revision 1.121.2.1
diff -u -r1.121.2.1 gimpimage.c
--- app/gimpimage.c 2000/12/27 17:55:19 1.121.2.1
+++ app/gimpimage.c 2001/06/12 00:00:57
@@ -1456,7 +1456,7 @@
for (list = gimage-layers; list; list = g_slist_next (list))
{
layer = (Layer *) list-data;
- layer_delete (layer);
+ layer_unref (layer);
}
g_slist_free (gimage-layers);
g_slist_free (gimage-layer_stack);
@@ -1472,7 +1472,7 @@
for (list = gimage-channels; list; list = g_slist_next (list))
{
channel = (Channel *) list-data;
- channel_delete (channel);
+ channel_unref (channel);
}
g_slist_free (gimage-channels);
}
Given the confusing API used here it's not surprising that this could happen.
Gimp HEAD already had this hole plugged, but not because someone found and
fixed it, but because the code has already become much cleaner and we avoid
to wrap around basic functions like gtk_object_[ref|unref].
I don't consider this a clean solution but since it's a very small change,
we should be able to evaluate easily if it is a correct fix. A better fix
can be found in CVS HEAD, but I would prefer not to do too much changes to
1.2 if it can be avoided.
I haven't tested the patch much so far, so please torture it.
Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 4.2 tentative plans
I'm going to be out of town for 2 weeks starting Friday. I'd like to alpha freeze 4.1 when I get back. This means we're looking at late August or so for 4.2 release. My big concern is with the Canon driver. If Andy doesn't have time to fix it, and nobody else steps up, I'm going to try to back out Andy's changes to at least restore the driver more or less to the state it was in 4.0. I'd like decide that one way or the other before alpha freeze if at all possible; if Andy has time after that, but before beta, we can try to get the new driver working. The other thing I want to try to do is get the ink change stuff for the Epson 480/580 working. The folks at Epson sent me some code; I think I understand the command sequence needed, and I've asked them to check it for me. That's likely to go in after initial alpha. Finally, I'm trying to arrange for testing on the Stylus Pro printers; it would be really nice to ship 4.2 with support for the entire printer range. Gimp folks, how would this play into your schedule? Do you have any plans for a 1.2.2 release at any point? -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 4.2 tentative plans
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: Gimp folks, how would this play into your schedule? Do you have any plans for a 1.2.2 release at any point? we would like to do a 1.2.2 release very soon now. Actually the plan was to do it this week, but we are still waiting for an OK from the gimp-help crew and of course the bug-fat-piggy-gimp-patch needs some testing before a release, so it might be delayed slightly. I'm sure we don't want to wait till August/September however. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 4.2 tentative plans
From: Sven Neumann [EMAIL PROTECTED] Date: 12 Jun 2001 02:36:20 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: Gimp folks, how would this play into your schedule? Do you have any plans for a 1.2.2 release at any point? we would like to do a 1.2.2 release very soon now. Actually the plan was to do it this week, but we are still waiting for an OK from the gimp-help crew and of course the bug-fat-piggy-gimp-patch needs some testing before a release, so it might be delayed slightly. I'm sure we don't want to wait till August/September however. OK, that's fine. We're not ready now with 4.1. 4.0.5 has a few improvements (most notably support for the very popular Epson Stylus Color 777/680), but it's not really a must-have. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 4.2 tentative plans
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: OK, that's fine. We're not ready now with 4.1. 4.0.5 has a few improvements (most notably support for the very popular Epson Stylus Color 777/680), but it's not really a must-have. I don't think we are up to version 4.0.5 in the gimp-1-2 branch (nor in HEAD). Do you suppose we upgrade before 1.2.2? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
