GNOME Bugzilla – Bug 479875
performance problem drawing a complex selection
Last modified: 2010-08-26 18:55:21 UTC
Steps to reproduce: 1. open a large JPG file (5 MB or larger)with a prominent color. 2. choose the tool "select by color". 3. select the prominent color. Gimp crashes!!! This does not happen with small JPG-files Stack trace: Other information: Windows XP CPU: Pentium 4 HT 3 Gh Memory: 2.5 GB Harddisk: 100 GB free
It would be nice if you could upload an example file somewhere and post an URL here so that we can try to reproduce the problem.
I would also be helpful if you specified the exact tool options you use that causes the crash.
(In reply to comment #2) > I would also be helpful if you specified the exact tool options you use that > causes the crash. It happens with any option!
With Gimp 2.2.17 and Gimp 2.3.19 there is no such problem. This makes me think the code has changed, and not in a good way...
This might be a rendering problem rather than a Select by Color problem. Does RC3 crash if you make the selection in 2.3.19, save as .xcf (which will keep the selection), and open the image in RC3?
(In reply to comment #5) > This might be a rendering problem rather than a Select by Color problem. Does > RC3 crash if you make the selection in 2.3.19, save as .xcf (which will keep > the selection), and open the image in RC3? I just figured out that the shortcuts "CTRL-C" and "CTRL-V" work, but you can't use the menu's to copy and paste (neither any other menu when you first click on the picture to select a color with "select by color". Maybe this will help the programmers to correct the bug...
Created attachment 96166 [details] Result of bug This pic shows the result of Select by Color on a moderate sized jpg
GIMP 2.4 RC3, Vista, 2GB RAM, AMD A64X2 I can confirm this. But GIMP doesn't exactly crash, in my case. What happens is that the part the tool selects starts to flicker and if you try to open any menus, only the outline of the menu opens around a transparent menu. But, if I do a CTRL-Z, I can usually undo the select and the program sort of recovers. I tried this with a tiny jpg and the problem didn't occur, but with even a 667 x 500 jpg, the problem occurred. Trying this on any large image causes this problem, also.
Most probably this is a performance problem in the Windows GDK backend. It seems to have problems rendering the selection outline.
We still need an example image to reproduce this report.
(In reply to comment #10) > We still need an example image to reproduce this report. http://picasaweb.google.nl/JefRegal/NatuurfotoS/photo#5114512589173205138
As expected this is not a problem on Linux/X11. We did some changes to the selection drawing code compared to GIMP 2.2. Someone should investigate what effect these changes have for calls into GDK. It would also be helpful if someone could use a debugger on Windows and find out where exactly GIMP gets stuck.
Could be a duplicate of bug #468658 or vice versa.
Michael, is this reproducable for you?
I have a question concerning this; if this tool is "Select By Color", why is there a Drop-Down Menu for "Select By:" ? It would make more sense if the tool options remained the way they are shown to be in figure 12.13 of the help PDF. Anyway, sometimes this tool works and sometimes it selects too much (it breaks out) and makes GIMP bog down. The "Fuzzy Select" has the same problem, but not as bad.
(In reply to comment #14) > Michael, is this reproducable for you? The same problem still exists in Gimp 2.4.0 and in Gimp 2.4.1
*** Bug 493284 has been marked as a duplicate of this bug. ***
*** Bug 495652 has been marked as a duplicate of this bug. ***
*** Bug 498550 has been marked as a duplicate of this bug. ***
Comment #8 is exactly my case....so, how can this be fixed? Or can it be fixed?
(In reply to comment #8) > GIMP 2.4 RC3, Vista, 2GB RAM, AMD A64X2 > > I can confirm this. But GIMP doesn't exactly crash, in my case. What happens > is that the part the tool selects starts to flicker and if you try to open any > menus, only the outline of the menu opens around a transparent menu. But, if I > do a CTRL-Z, I can usually undo the select and the program sort of recovers. > > I tried this with a tiny jpg and the problem didn't occur, but with even a 667 > x 500 jpg, the problem occurred. Trying this on any large image causes this > problem, also. > Did you ever resolve this issue? Thanks! Melissa
If it was resolved, this bug report would have changed state.
Sven Neuman...You are a smart-ellic! You could have simply said "no M'am it hasn't...keep checking back for a change of status" If it's hard for you to be polite, maybe you can get someone to make a polite response template for answers to questions that you may get all-too-often, if that is the case. This is my first time using this board, so I am not familiar with how things work yet. I'd appreciate your understanding. Sincerely, Melissa
I am also experiencing the problem, not only with "select by color", but also with "fuzzy select" and "free select" (at least after using any of the others). I also suspect that the problem isn't the selection itself, but the rendering when complicated selection is active: one sees the re-rendering of the image slowly going on and if we are careful enough to use only the right keyboard shortcuts and mouse clicks, and wait long enough, we can get on with the work (for instance, if we activate the bucket fill, click on the selection and immediately deselect everything, the program gets responsive again and presents the selection filled). I am using Gimp 2.4.1 now, but 2.4.0 presented the same problem. I tried several values for the number of undo levels, memory used by tiles and undos and I didn't found any improvement or worsening. I use a P4 HT 3.2 with 1 Gb RAM and Win XP SP2, mainly with JPG photos with 8 Mpx.
The problem is in the drawing routines. There is nothing you can do to fix it but looking at the code. This needs to be fixed in the Win32 backend of GDK or an optimization in the GIMP code could be tried. Since the main development platform is not affected, this is not likely going to be solved until someone who is actually using Windows sits down and does the necessary work to track down and fix this problem.
*** Bug 472828 has been marked as a duplicate of this bug. ***
*** Bug 468658 has been marked as a duplicate of this bug. ***
*** Bug 502673 has been marked as a duplicate of this bug. ***
If could be of some help I'd found that the problem seems to shows up zooming the image below 100% or, maybe more correct, when the selected area showed in the image window is very large. Hope this helps a bit the gimp4win devs.
I guess we should try to simplify the selection boundary somehow, probably depending on the zoom ratio. It might help to use a tile-pyramid for the selection mask, similar to the projection. The selection boundary could then be created from the scaled-down mask. But I guess that this wouldn't solve all problems.
This should be on the 2.4 milestone. If it turns out that the fix is too complex (such as the approach I outlined in comment #30), then we can postpone it to 2.6.
if I could toss my 10c, I would suggest to drop that annoying crossing-eyes moving dashes to a different-looking boundary masking - a still plain red mask would be great to me.
... unless you work on a red image.
you gotme - so how about a (very mildly) flashing red mask?
For who was looking for a workaround (not a solution...) Simply grow selection of 1 pixel, i can do even when everything is flickering seems solve slowing down and flickering 1 pixel grow don't change much the selection, as visually perceived , but greatly semplify it,(simplify the staus of many partially selected pixels) and flickering stop as soon this is done.(at least on my PC ) (then done you may even shrink back selection of 1 pixel, if needed)
The workaround would be to increase the marching ants speed to 1000 (instead of the not so recent default 100). The only regression I could find is the change of the default from 300 to 100 (done in revision 20709, 2006-09-04). Although the implementation on windows is less efficient than on Linux it is possible to bring GIMP down to its knees on Linux as well. With a 2560x2048 image pattern-filled with "Stripes Fine" and selected-by-color, with a marching ants speed of 10 (the minimum) there is no interaction possible anymore. To overcome the issue I think the marching ants speeds needs to get a priority below the user interface handlers. At the moment it is unconditionally g_timeout_add. Changing to g_time_out_add_full (G_PRIORITY_DEFAULT_IDLE, ...) makes the menu accessible again. Patch follows.
Created attachment 102120 [details] [review] marching ants with G_PRIORITY_DEFAULT_IDLE ok to apply?
at the price to became pesky, I'll try again with my suggestion: why not to take this opportunitiy to make the selection stuff better? I pointed out before how bothersome are those moving ants for my eyes, so I find a better solution to have an inverted masking of the UNselected zones (just as for the crop selection where you see the outside to crop grayed) because in such a way, I have a clear idea of what is selected and what is not, a thing that I do not have with those ants, expecially having very small selected areas. Keep in mind that I'm a user not a dev so my suggestion is devoted to a better use from my side not to ease the devs job, therefore I apologise if my post is out of topic in some extent.
Please commit this change to both branches. fabius, your comments are inappropriate here as they are not strictly related to the bug report. What you are suggesting would need to be discussed on the gimp-developer mailing-list first.
Hans, can you please commit this to trunk too?
Done already: 2008-01-04 Sven Neumann <sven@gimp.org> Merged from gimp-2-4 branch: * app/display/gimpdisplayshell-selection.c: draw marching ants with G_PRIORITY_DEFAULT_IDLE; fixes bug #479875.
Should we also change the default marching-ants speed back to 300? Perhaps only on the Windows platform?
I was about to merge it myself but it took some time to make gimp-2.5 compile at all on win32. When I was finally through it I got a conflict because Sven was too fast ;) Regarding the marching ants speed I don't think we need special casing on win32. It just gets the 100% cpu load a little bit faster there. But I'm uncertain if 10Hz of display update is appropriate at all. If you look at the selection from my test image the only thing visible is some quite disturbing flickering. Of course that wont change much with 300ms cycle instead of 100. Some more smart selection visualization - as mentioned by Sven above - seems to be the better (long-term) solution.
Shouldn't hurt to reduce the speed somewhat. I have applied this to both branches. 2008-01-04 Sven Neumann <sven@gimp.org> * app/config/gimpdisplayconfig.c: changed the default marching ants speed to 200. Lowering the priority and severity of this bug report...
*** Bug 506806 has been marked as a duplicate of this bug. ***
*** Bug 508632 has been marked as a duplicate of this bug. ***
We don't have a clever plan on how to improve this and it should not block the release. Let's bump it to the 2.8 milestone.
For some users, the flickering has been traced back to a bug in Nvidia's drivers.
Removing from any milestone but keeping it accepted.
The slow code is gone, this bug is fixed: commit be2bd189cd6d96c63e4a8a41cff98486e740ebf4 Author: Michael Natterer <mitch@gimp.org> Date: Thu Aug 26 20:52:52 2010 +0200 app: completely switch to cairo-drawing the selection and remove all old selection drawing code. Thanks to Benjamin Otte for pointing out the right optimization. Also fixes bug #479875 - performance problem drawing a complex selection. app/display/gimpcanvas.c | 184 ------------------- app/display/gimpcanvas.h | 7 - app/display/gimpdisplayshell-draw.c | 26 ++- app/display/gimpdisplayshell-draw.h | 7 +- app/display/gimpdisplayshell-selection.c | 289 +++--------------------------- 5 files changed, 53 insertions(+), 460 deletions(-)