GNOME Bugzilla – Bug 51547
Multiple Filters / Operations should not be allowed
Last modified: 2018-05-24 10:30:41 UTC
It is possible of run a filter (any) and while Its doing this, still apply another, or paint on the image This problem would be fixed by locking the image to anything other than zooming, panning, and canceling the filter.
Locking the whole image may be a bit excessive, because you might want to be able to run a very time-consuming plug-in on one layer of the image (e.g., resynthesyser) while you are painting or performing other operations on the other layers. But this can only work if the plug-in touches only one layer. Currently, the gimp plug-in protocol does not provide enough information to be sure that a plug-in will not read or modify the other layers or masks in the image. Some modifications to the plug-in protocol would be necessary in order to allow any kind of "smart" locking of the image.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Reassigning to current CVS since this is a wishlist item and will not be fixed in the 1.2 tree.
*** Bug 37632 has been marked as a duplicate of this bug. ***
I am changing the severity of this bug report from "enhancement" to "normal" because the lack of locking can lead to data corruption, as reported several times (including bug #37632). This can be fixed by implementing image locking (quick fix) or layer locking (enhancement, better solution). If image locking is ever implemented, then this bug can be closed and a separate enhancement proposal can be submitted regarding a more flexible locking system based on layers, but requiring changes in the plug-in protocol.
Changed target milestone of several bugs to 2.0 - these are not features, and don't look to me like blockers for a pre-release, but they have to be addressed before 2.0. Dave.
Bumpiong to 2.2. Dave.
*** Bug 165326 has been marked as a duplicate of this bug. ***
Moin. So...it's early 2.3 and I vote for transparent layer locking: if a pixel region/tiles are requested for a layer that is locked, this request is not granted until the layer is released. (i.e. previous pixelregions/tiles are freed) Maybe locking related methods can be added to the plug-in protocol, as an addition. (For example, a plugin could choose to get an exception if it tries to modificate a locked layer, instead of being put on hold) I had not ever dig into that part of the code - would it be too complicated?
With the recent changes in trunk, plug-ins can now work in parallel on different layers of the same image. This doesn't solve all the problems outlined here, but it makes things a lot worse.
*** Bug 554763 has been marked as a duplicate of this bug. ***
Current interface doesn't even show that there are two (or more) plugins working concurrently. I've tried a couple minutes ago the following operations: - new image, A4, 300dpi, paint something, gaussian blur, - new layer, paint something, emboss, - switch to previous layer, paint, emboss, - switch to next (did previous emboss finished?), paint - ka-BOOM! - garbage on screen. Working on one layer looses data, working on more is even more painfull, because I don't know what's going on. Why locking the whole image is a bad idea? It would solve the problems at the price of some precious time. But I'd like to wait that time, than to recreate my images later, spending even more time. On the other hand, locking layers is very bad idea, as is involves designing locking protocol, various concurrency problems, etc - and not every plugin writer is savvy in concurrent programming, deadlock resolving, etc., so this wouldn't work anyway. Maybe putting the plugin operations on a stack (like GEGL operations?) might be another solution - but that way picking the proper options for the next plugin is very hard, as I couldn't see in preview what is the result of previous operation. After some thinking, I think locking whole image is the only solution where the good outcomes outnumber the bad. The only question in my mind - is GIMP noticed that the plugin crashed, so it would release the plugin acquired image lock? If yes - I vote for image locking with all my hands. :) Cheers, Marcin
*** Bug 557737 has been marked as a duplicate of this bug. ***
I too would vote for image locking. Most systems will be bogged down anyway when executing a filter that takes long (I know, I know, multicore and everything), so you might end up have aliasing issues in mouse movements etc as well.
*** Bug 682378 has been marked as a duplicate of this bug. ***
*** Bug 759936 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/7.