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 149616 - complex selections cause extreme slowdown
complex selections cause extreme slowdown
Status: RESOLVED INCOMPLETE
Product: GIMP
Classification: Other
Component: User Interface
git master
Other Linux
: Normal minor
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 302822 (view as bug list)
Depends on:
Blocks: 141797
 
 
Reported: 2004-08-08 04:50 UTC by david gowers
Modified: 2007-12-06 09:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description david gowers 2004-08-08 04:50:43 UTC
steps to reproduce:
1.create a new 1024x1024 image
2.enter qmask mode
3.fill the image with a 2x2 checkerboard pattern (or some other high-noise pattern
4.exit qmask mode

now there are long pauses before and after drawing, even when the selection is
invisible. the right thing to do is to only create the data used to draw the
selection when it is actually going to be used. i'll look into this.
Comment 1 Sven Neumann 2004-08-08 10:09:55 UTC
This is a known problem and I don't think there's much that can be done about this.
Comment 2 Sven Neumann 2005-05-04 20:17:04 UTC
*** Bug 302822 has been marked as a duplicate of this bug. ***
Comment 3 Sven Neumann 2005-05-04 20:55:06 UTC
Note that the actual problem is probably that GDK cannot handle the amount of
segments we are asking it to draw.
Comment 4 Nick Smith 2005-05-27 05:05:21 UTC
I've found a temporary work around for this particular problem.  I run at
1600x1200 resolution and even simple and small selections in a large image
window (where a 1024x1024 image fills the entire window without the need to
scroll) cause GIMP to slow down.  However, when I shrunk the window way down
(like 256x128 pixels of image area or smaller), I noticed a big increase in the
speed and GIMP responds better and acts to changes much more quickly.  If you
need complex selections (or to make the program run a bit faster in general),
shrink the window before beginning to make the selection to speed up GIMP.  The
smaller the window gets, the faster GIMP will run.
Comment 5 david gowers 2006-10-04 03:32:37 UTC
Nick: Yes. But I cannot do that ;The Ion3 windowmanager auto-maximizes windows into the respective frames owning them.
Comment 6 Sven Neumann 2006-10-05 06:16:35 UTC
David, if you need to have a discussion with Nick, please have it in private email. Your comment is irrelevant here.
Comment 7 Sven Neumann 2006-12-22 08:01:58 UTC
The test case given in comment #1 doesn't cause a noticeable slowdown here. The X server starts to consume about 5% CPU load and GIMP shows up at about 1%, I don't think that can be called an extreme slowdown. But this probably depends very much on the graphics card and the X server being used.

At some point I looked into optimizing this code but I am afraid that there is not much potential for optimizations. At least I couldn't think of any. Perhaps it's about time that this bug is closed as WONTFIX.
Comment 8 david gowers 2006-12-22 08:54:09 UTC
Some improvements have been made recently (your December 5 fix related to animation timeout?) and indeed, painting is quite responsive. There is still a lag at the end of a stroke, it just doesn't prevent you from beginning another stroke.
(this lag also effects window title updates, so for instance if I add a layer, the titlebar will reflect it 2 seconds later)

Try panning, though -- it is fast usually, but dog-slow with a complex selection. ~8 frames per second (more like 5 and several disjointed halves) with a checkerboard selection versus ~20 frames per second with a simple shape selection, on a 1.2ghz machine. I think the GCs coordinates are being translated during instead of after the pan operation. Translating them during is only sensible when the selection is visible.

There is also a related bug I discovered today, that causes Gimp to lock up (preventing the X server and WM from doing anything until GIMP is killed.)
(bug #388588 )
Comment 9 Sven Neumann 2006-12-22 10:31:27 UTC
I think you should consider to change the graphics card or try a different driver. I do not observe any noticeable slowdown when panning with complex selections. There is also no such thing as GC coordinates. Please refrain from making assumptions about the code and stick to the facts.
Comment 10 Nick Smith 2006-12-23 19:37:54 UTC
I'm not sure if you'll find it handy, but these are some clues:

1.  Increase the window size of the image a lot and the effect amplifies a lot.  Rather than working with a window size of 400x300 (interior space where the image actually goes), use one with 1200x900 and the effects are much more noticable.
2.  While the window takes several seconds to update itself, the "marching ants" effect bordering the selection continues on.  Try creating the checkerboard pattern in a 1x1 grid of pixels, select one of the colors to get a checkerboard pattern selection, then make some change.  You'll notice that the "marching ants" effect continues on nonstop while the changes aren't taking effect.  It's as if the "marching ants" effect has "high" CPU processing priority whereas the change you made has "normal" priority.  With a small window size, this isn't as noticable, but when you increase the window size to show more of the selection, the effect becomes far too strong and the program seems to have crashed since it's taking so long, even though the border from the "marching ants" effect is still changing.

I suspect that the issue is with the "marching ants" effect.  Even with my mid-range modern system (3 GHz Pentium 4 processor, 250 GB 7200 RPM hard drive, GeForce 7600 GT video card using PCI-express, Windows XP Pro SP2, 1920x1440 resolution at 32-bit color, etc.), I get this lagging effect.  Even when I had my older system before all the upgrades (Windows 98 SE, 40 GB 7200 RPM hard drive, 1.05 GHz Athlon processor, Radeon 7000 video card using AGP 4x, 1600x1200 resolution at 32-bit color), the effect is the same, only somewhat more noticable.
Comment 11 Sven Neumann 2006-12-24 11:30:30 UTC
I don't observe such lags here.
Comment 12 Sven Neumann 2007-09-30 17:18:04 UTC
Does this behavior still show up for you with 2.4.0-rc3 or newer ?
Comment 13 Michael Schumacher 2007-12-06 09:35:08 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!