Re: image map trashes image
On Tue, Nov 23, 1999 at 07:39:22AM +, Nick Lamb <[EMAIL PROTECTED]> wrote: > rather than a missing feature, I wonder if all these tile-level probs > are one thing or many??? The one who finds out should be forced to fix it ;) Maybe we can find this before 1.2. And when these problems go away after COW was disabled we might have found the place where it happens. BTW, --with-threads is still horrbly broken. > but what SHOULD happen if I try to Blur a layer while Rotating the whole > image that layer is part of? A corrupted image seems like a plausible > result to me... Actually, I would expect that the gimp rotates and then blurs, just as it was told. For 1.2, though, a corrupted image is the best we can get. > Yeah, can you file a bug for anything which actually blows up in a > reproducible manner when used for the multiple plug-ins/ multiple targets > case? Oh, I report any bugs I find that I can reproduce. But this kind of bug is difficult to reproduce. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: image map trashes image
On Tue, Nov 23, 1999 at 04:28:48AM +0100, Marc Lehmann wrote: > It often ends up with gimp spinning in an endless loop or a segfault or > corrupted images (including undo). Eeek! This is definitely something wrong in the current implementation rather than a missing feature, I wonder if all these tile-level probs are one thing or many??? > > case I can't see that they should be. I remember that context (brushes, > > gradients, palette settings) is global and that can cause problems for > > scripts that _change_ them, but shouldn't for most plug-ins. Is there > > anything else? > > Yes, tile access is also not locked. However, most users seem to have > learned that gimp is single-task-per-app for some operations, and > single-task-per-image for almost all operations. I'm not sure what you want here, I agree that running something on Layer1 and then something else on Layer2 should work (modulo lack of contexts) but what SHOULD happen if I try to Blur a layer while Rotating the whole image that layer is part of? A corrupted image seems like a plausible result to me... > > Or have I missed something dreadful? > > Not really. I also think it should work (modulo image corruption), but in > practise it does not seem to behave that nice. But that might be another > bug. Yeah, can you file a bug for anything which actually blows up in a reproducible manner when used for the multiple plug-ins/ multiple targets case? At least tigert and I are regularly using Gimp in this way, and I wouldn't be surprised to hear that others do too (seems natural to me) Nick.
Re: image map trashes image
On Mon, Nov 22, 1999 at 06:45:15PM +, Nick Lamb <[EMAIL PROTECTED]> wrote: > > one oepration (regardless of which) is being done at the same time. It gets > > much worse when you do it on the same image. > > Are these "bad things" fatal? It often ends up with gimp spinning in an endless loop or a segfault or corrupted images (including undo). > case I can't see that they should be. I remember that context (brushes, > gradients, palette settings) is global and that can cause problems for > scripts that _change_ them, but shouldn't for most plug-ins. Is there > anything else? Yes, tile access is also not locked. However, most users seem to have learned that gimp is single-task-per-app for some operations, and single-task-per-image for almost all operations. > probably lock this in a future version of Gimp, but even this should not > cause crashes, and so is not critical for 1.2 The only thing that should be done for 1.2 is to make it stable, yes. > Or have I missed something dreadful? Not really. I also think it should work (modulo image corruption), but in practise it does not seem to behave that nice. But that might be another bug. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: image map trashes image
On Mon, Nov 22, 1999 at 02:49:50PM +0100, Marc Lehmann wrote: > In current gimp you will notice lot's of bnad things happening when more then > one oepration (regardless of which) is being done at the same time. It gets > much worse when you do it on the same image. Are these "bad things" fatal? For the multiple filters, multiple targets case I can't see that they should be. I remember that context (brushes, gradients, palette settings) is global and that can cause problems for scripts that _change_ them, but shouldn't for most plug-ins. Is there anything else? The multiple plug-ins/ tools with single target case is harder, we could probably lock this in a future version of Gimp, but even this should not cause crashes, and so is not critical for 1.2 Or have I missed something dreadful? Nick.
Re: image map trashes image
On Mon, Nov 22, 1999 at 01:18:17PM +0100, Michael Natterer <[EMAIL PROTECTED]> wrote: > Image map modifies the image in place and it's possible to do another > operation while an image map tool dialog (e.g. threshold) is active. In current gimp you will notice lot's of bnad things happening when more then one oepration (regardless of which) is being done at the same time. It gets much worse when you do it on the same image. > This is buggy, but I have no idea how to fix it (HALT-ing the active > tool at hundreds of places may be a workaround but is really ugly...) And would not fix the problem for non-tools. > any ideas?? Add some dependency checking, some locking mechanism, some queueing mechanism and a tree undo in gimp-1.3 ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
image map trashes image
Hi all, while modifying the image map tools' ui I noticed that there's a strange side effect. Image map modifies the image in place and it's possible to do another operation while an image map tool dialog (e.g. threshold) is active. So the "other operation" (try e.g. /Image/Colors/Desaturate) operates on the mapped image which was image_map_apply()'ed but not yet image_map_commit()'ed. Moreover, the current (mapped) drawable is pushed to the undo stack, so it's not possible to get back the image you had before invoking the image map tool. I tried to insert "active_tool_control (HALT, active_tool->gdisp_ptr)" as first command in "undo_push()" and "undo_push_group_start()" but this only ensures that the pushed undo is correct. The image resulting from the "other operation" may or may not (depending on "other op."'s implementation) be based on the not-yet-commited mapped image. This is buggy, but I have no idea how to fix it (HALT-ing the active tool at hundreds of places may be a workaround but is really ugly...) any ideas?? bye, --Mitch
