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,
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
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
Bumpiong to 2.2.
*** Bug 165326 has been marked as a duplicate of this bug. ***
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
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. :)
*** 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.