GNOME Bugzilla – Bug 645345
'Color Management' display filter causes performance problems
Last modified: 2012-08-31 17:19:37 UTC
For the past several weeks, the select tool has been difficult to use. It expands and shrinks slowly with user input, and it is difficult to move around on the screen, because it moves several seconds after user input, and it's movement is not smooth, but coarse / jerky. The tool works best if there are no guides.
Is it only the rectangle tool, or are other tools slow too?
I've only had trouble with the rectangle select tool.
Hmm, not even with the ellipse tool?
Nope, I just tried that: it works fine for resizing and moving around.
Here are some more 'slow-to-respond' tools: 1) The crop tool behaves the same as the rectangle tool: it is slow to 'grow' the rectangle when I first start to make my selection, and it is slow - a second or two - to respond to repositioning with the mouse, and often the mouse pointer does not finish in the same spot as when I have begun to drag the selection to a new position. 2) The rotate tool rotates OK if I just preview the image, but if I preview the grid, the picture is very slow to rotate. 3) I don't know if I should file this one as a separate bug, but with the rotation tool, if I first view -> grid (turn the grid on) and then select the rotate tool, as soon as I start to rotate, the black grid vanishes, but reappears when I finish with rotate. I'm wondering if I may be too far ahead the the bleeding edge: I'm using glib-2.28.2 and gtk+-2.24.4, gegl-0.1.7, and cairo 1.11.3.
What graphics hardware/driver do you use?
lspci shows this as the video card: 1:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9500 GT] (rev a1) I'm using the nvidia driver from nvidia.
Hm, I was hoping for ATI, since we had two cases ot pathetic slowness on ATI already. And I'm using cairo/pixman from git myself, so I don't think that's the problem.
Can you try again please with current master and its bumped dependencies? It's not unlikely that the new pixman and cairo will make the slowness go away.
I updated the pixman and cairo, rebuilt gtk+-2.24.4, and then updated and compiled the current gimp master. There is no change.
I still have no explanation why the ellipse select tool (which clearly is just a superset of rect select) doesn't show this behavior. Can you somehow debug it to check where it spends all the time?
I've got no way to debug this unless there is some way to open the source in an IDE where I can set up some checkpoints and step through the code. I did try the ellipse and there is no problem. I also checked with gimp-2.6.11 and there is no problem with the rectangle select tool. I'm running the gimp master on my fastest machine (64 bit quad that thinks it has eight cores) on slackware 13.1 / kde-4.4.3. I'll see what happens on an older, slower machine. I'll report back after I get that done today.
Make sure debug symbols are available (install them or compile GIMP yourself) and then use sysprof
I just compiled gimp-master on my much slower slackware 12.2 / kde-3.5.9 laptop and there are no problems with the rectagle, so there's got to be a problem on this much faster up-to-date machine. Please remove this as a bug. I'll continue to track things and see if I can figure out what is causing the problem on this one machine.
The bug resurfaced on my slow laptop, and this time I note that the ellipse is slow to move on the screen, which is the problem that I reported with the original report.
I installed sysprof, ran gimp-master, and moved the rectangle around. Descendants shows: gimp_color_display_stack_convert_surface: self: 0.00 cumulative 84.40 gimp_color_display_convert_surface: self: 0.00 cumulative 84.40 cdisplay_lcms_convert_surface: self: 15.96 cumulative: 84.40 in file /usr/lib/liblcms.so.1.0.19: self: 68.40 cumulative: 68.40 g_free: self 0.00 cumulative: 0.04 free: self:0.00 cumulative: 0.04 _int_free: self: 0.04 cumulative: 0.04 I can attach the output from sysprof, if you want it.
And if you remove/uncheck View -> Display Filters... -> Color Management?
That fixes it: The rectangle moves around freely :-) Now: what about color management?
We could try to optimize cdisplay_lcms_convert_surface(), for example by not allocating and freeing memory each call Most of the time is spent in liblcms
*** Bug 650095 has been marked as a duplicate of this bug. ***
The bug is still there. I can see it with versions 2.7.4 and the new 2.7.5. What becomes *very* slow with the Color Management display filter activated : - rectangle selection - ellipse selection - crop tool - zoom in / zoom out and probably some other tools. I have two machines with Nvidia and ATI graphics hardware and the bug is there for both. I've seen that this bug is not assigned to the target milestone 2.8, but I think it should IMHO.
I have the same problem when I enable color management in gimp-2.8.0-RC1. I used 2.6.12 before WITH color management w/o slowness using the same .icc files on the same hardware. Gerard.
Yes, the bug is still there in Gimp 2.6.8-RC1. The problem is that this bug is not in the 2.8 bug list. I've sent several mails to the development team (on the devel mailing list) about this, but I didn't receive any answer. Perhaps ypu could write them too, and they will at last do something... RB
Could you give me a link to the dev mailing list? How many places can one send a bug report about gimp besides this one? Gerard.
I have similar problems with the 'Color deficient' display filter. Rectangle selection and crop tool are slower then, but not ellipse selection or zoom in/out. The other display filters work well. I tried it in 2.8RC1 on Windows. Mailing list vs. Bugzilla: In my experience Bugzilla is the first and only address to report GIMP bugs. The developer mailing list is for discussions, mainly about development problems or enhancements. You could try IRC to discuss them first, too - but at the end bugs should be reported in Bugzilla. To me it seems the development team doesn't have much time now. Hopefully this is due to the final preparations for 2.8.
*** Bug 673867 has been marked as a duplicate of this bug. ***
Let's put this on the 2.8 milestone at least
In order to fix this, we would have to insert a cache of the display-filtered projection (colorblind, color correction etc are all display filters). This is not something I would normally want to see in a stable bugfix release, but since it's indeed a regression, we'd be willing to accept a clean patch that implements such a buffer.
Hi, nice to see this regression is finally taken into account by the development team. I must admit they have a lot of pression these days... Anyway, I tried to fix this bug myself, but it seems to be too complicated for me... However, if someone send a patch, I can test it. RB
*** Bug 674203 has been marked as a duplicate of this bug. ***
*** Bug 675603 has been marked as a duplicate of this bug. ***
*** Bug 675900 has been marked as a duplicate of this bug. ***
How about removing the 'Color Management filter' from the 'Active filters' list by default, until the problem is solved and reenabling it after that?
*** Bug 676756 has been marked as a duplicate of this bug. ***
*** Bug 676926 has been marked as a duplicate of this bug. ***
http://www.gimpchat.com/viewtopic.php?f=4&t=4057&start=10#p50056 claims that liblcms 2.3 has an impact on this - requiring some changes to the source, unfortunately these changes are not available there. If someone is subscribed to the forum, it would be nice if you let the author know about this bug report and ask them to attach the changes here (do not attach the zipped binaries from that post!).
Ah, there is a bug for that: bug #675558
Created attachment 215316 [details] [review] An attempt to reduce color management cost Please test
I tested your patch with Gimp 2.8.0 compiled on a Linux Debian Squeeze (amd64 architecture). Processor is an Intel Xeon E5430 @ 2.66 GHz, 4 GB RAM. With the patch, the following functions are now very fluid : rectangle selection, crop, zoom with magnifying glass selection. The speed is nearly the same with and without color management enabled. However the circular/elliptic selection is still a bit slower with color management enabled, but it is very usable. In any case, I see a dramatic improvement by using this patch. A big thanks! RB
Very nice, another small optimization would be not to create the smaller surface if we are going to render the entire surface anyway.
I confirm that the patch significantly improve the speed. The paintbrush, pen, heal, clone, smudge are works quite well. Rectangle and elliptic selections, crop still seems to be a little bit sluggish in comparison with the case without color management.
Created attachment 215388 [details] [review] Second attempt A new patch implementing the small optimization suggested above
I don't see any improvement with this second version of the patch. However, I found accidentally that reinstalling the line : cairo_surface_mark_dirty (shell->render_surface); seems to make the selection more responsive. But perhaps it is an illusion... RB
Created attachment 215482 [details] [review] Last attempt My last attempt. Trying to reduce colour management cost when using ellipse selection tool as well.
The selection tools seem to be fast enough with the latest patch, but it seems that rectangle and ellipse selection tools suffer from different bug (I just have opened the bug #677375). The bug #677375 is more easy reproducible with color management turned on (I used GIMP from current git, gimp-2-8 branch, with the latest Massimo's patch from here), but it is also reproducible with color management turned off.
Review of attachment 215482 [details] [review]: committed a slightly changed patch commit 41ce828243cd751618ac8ea90916f8aa880faeb4 Author: Massimo Valentini <mvalentini@src.gnome.org> Date: Sat Jun 9 15:36:34 2012 +0200 Bug 645345: 'Color Management' display filter causes performance problems
*** Bug 677668 has been marked as a duplicate of this bug. ***
*** Bug 680169 has been marked as a duplicate of this bug. ***
I just tried to reproduce it with the current GIMP 2.8.2 on Windows 7, 32 bit. As expected from http://git.gnome.org/browse/gimp/plain/NEWS?h=gimp-2-8 rectangle select, crop, zoom in/out and rotation tool with default settings work well, even with activated color management and color deficient view display filters. Can you please test with the current 2.8.2 Windows build at http://gimp-win.sourceforge.net/ and report back during the next 6 weeks? If it doesn't occur anymore feel free to close this bug as RESOLVED FIXED. Thank you.
I just got a notification about this bug. I use Linux by the way but as far as I'm concerned this bug can be closed. Incidentally:I noticed Gimp-2.8.2 now also supports lcms2. Gerard.