After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 51547 - Multiple Filters / Operations should not be allowed
Multiple Filters / Operations should not be allowed
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal normal
: Future
Assigned To: GIMP Bugs
: 37632 165326 554763 557737 682378 759936 (view as bug list)
Depends on:
Blocks: 101604
Reported: 2001-03-02 00:28 UTC by ideasman
Modified: 2018-05-24 10:30 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description ideasman 2001-03-02 00:28:06 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.
Comment 1 Raphaël Quinet 2001-03-02 17:18:33 UTC
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.
Comment 2 Raphaël Quinet 2001-04-26 18:13:48 UTC
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Comment 3 Sven Neumann 2001-06-19 00:23:06 UTC
Reassigning to current CVS since this is a wishlist item and will not
be fixed in the 1.2 tree.
Comment 4 Sven Neumann 2001-06-19 02:02:03 UTC
*** Bug 37632 has been marked as a duplicate of this bug. ***
Comment 5 Raphaël Quinet 2001-06-20 12:30:48 UTC
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.
Comment 6 Dave Neary 2003-07-23 16:19:12 UTC
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.

Comment 7 Dave Neary 2003-11-25 13:30:11 UTC
Bumpiong to 2.2.

Comment 8 Manish Singh 2005-01-26 18:17:35 UTC
*** Bug 165326 has been marked as a duplicate of this bug. ***
Comment 9 Joao S. O. Bueno 2005-01-26 19:39:02 UTC
Moin.'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? 
Comment 10 Sven Neumann 2008-06-05 06:31:38 UTC
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.
Comment 11 Sven Neumann 2008-10-03 14:30:37 UTC
*** Bug 554763 has been marked as a duplicate of this bug. ***
Comment 12 Marcin W. Dąbrowski 2008-10-04 09:49:17 UTC
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. :)

Comment 13 Sven Neumann 2008-10-24 19:42:45 UTC
*** Bug 557737 has been marked as a duplicate of this bug. ***
Comment 14 Fredrik Alströmer 2009-01-23 18:11:36 UTC
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.
Comment 15 Michael Natterer 2012-08-21 21:33:03 UTC
*** Bug 682378 has been marked as a duplicate of this bug. ***
Comment 16 Michael Natterer 2015-12-28 20:57:38 UTC
*** Bug 759936 has been marked as a duplicate of this bug. ***
Comment 17 GNOME Infrastructure Team 2018-05-24 10:30:41 UTC
-- 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: