GNOME Bugzilla – Bug 149616
complex selections cause extreme slowdown
Last modified: 2007-12-06 09:35:08 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.
This is a known problem and I don't think there's much that can be done about this.
*** Bug 302822 has been marked as a duplicate of this bug. ***
Note that the actual problem is probably that GDK cannot handle the amount of segments we are asking it to draw.
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.
Nick: Yes. But I cannot do that ;The Ion3 windowmanager auto-maximizes windows into the respective frames owning them.
David, if you need to have a discussion with Nick, please have it in private email. Your comment is irrelevant here.
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.
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 )
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.
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.
I don't observe such lags here.
Does this behavior still show up for you with 2.4.0-rc3 or newer ?
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!