GNOME Bugzilla – Bug 499150
toggleing of layer visibility/invisibility about five times slower than in 2.2.17
Last modified: 2008-10-30 20:05:21 UTC
Please describe the problem: toggleing the layer visibility/invisibility is very very slow if i for example want to see the impact of a "filter layer" to the whole image, i prefer to toggle the visibility of this layer (up to version 2.2.17) this doesn't make any sense with 2.4.2 Steps to reproduce: My Environment(but i know of others getting a similar effect): AMD Athlon 64 3200+ at 2.1 GHz, 1 GB RAM, nVIDIA GeForce 6200 AGP 256 MB, Windows XP Home Edition SP2, LCD-Display 1280x1024 Image 1024x1024 pixel, zoom 100% size of the window: width fitting the image's width, height at the margins of the screen's height One transparent layer, one image layer above toggle the visibility/invisibility of the image layer (by eye-icon in the layers dialog) Actual results: in GIMP 2.2.17, GTK 2.10.13 you can easily toggle the full visibility/invisibility of the image 5 times in a second in GIMP 2.4.2 barely 1 time... Expected results: GIMP 2.4.2 to be almost as fast as 2.2.17 Does this happen every time? yes Other information:
I think this is related too or even a duplicate of bug #479875.
It's not considerably slower than GIMP 2.2 for me, in particular not if you are looking at the image in 100% zoom. So this looks like a platform-specific issue and there is nothing we can do about it unless someone collects profiling data on this. One thing you could try to shed some light on it is to disable layer and channel previews in the Preferences and check if that makes a difference. Real profiling data would be much preferred though. Now don't ask me how to create such data on your operating system. It's your platform of choice, not mine.
hmm...enforcedly because of the lack of graphic-tablet-support in linux. For that reason - i like very much to use GIMP with my graphic tablet - i switched to Windows where it works. But that's another story... Nevertheless, i'll try to find out what i can do concerning profiling data.
I couldn't notice any difference with previews of layer and channels enabled or not. Due to an advice of Michael Schumacher i've installed GTK 2.12.1, libglib-2.0-0.dll(file version 2.14.2.0) and GIMP 2.2.17 and tested this constellation in the same manner as described above. It's as fast as GIMP 2.2.17 with GTK 2.10.13
Do you have a selection, perhaps even a complex selection, when you are testing this?
No. Just the two layers. Image and transparent layer. No other operations. No selection. No layer-mask, filters or something else.
We need profiling data then. Where does GIMP spend its time?
I really don't know which kind of data will be needed (scenario, details...) So i took the AMD CodeAnalyst and produced time based profiles. CodeAnalyst starts GIMP, i open an image 1600x1200 (zoom 50%) and start toggleing. Frequence: toggle when image window has been filled or cleared. CodeAnalyst starts profiling with a delay of 10 seconds, so only the period of toggleing will be measured (duration 10 seconds too). Here is a short cutout of the first modules involved (System data) Module Name 64-bit Total % Timer samples win32k.sys 39.61 4258 ntkrnlpa.exe 25.68 2761 AmdK8.sys 14.27 1534 liblcms-1.dll 6.59 708 gimp-2.4.exe 3.88 417 ntdll.dll 2.92 314 GDI32.DLL 1.65 177 LIBGDK-WIN32-2.0-0.DLL 1.20 129 hal.dll 0.76 82 LIBGLIB-2.0-0.DLL 0.70 75 LIBGOBJECT-2.0-0.DLL 0.52 56 LIBCAIRO-2.DLL 0.24 26 12 modules, Total: 10537 samples, 98.02% of total session samples And here the first the processes: Process Name Total % Timer samples gimp-2.4.exe 82.60 8880 System Idle Process 14.30 1537 System 1.56 168 Explorer.EXE 0.34 37 ... ... I'm afraid those kind of data will not help that much, so maybe someone could give me some advice what to do?
Hm... I've just discovered that if I draw on the image while it is slowly updating, the update is finished instantly. So it is not like it can't be faster for some reason...
err, I meant "paint", draw has a different meaning.
Looks like the update of the image display is of lower priority than some other task that is performed from an idle handler. I just wonder what this other task could possibly be.
I've profiled the astonishing "acceleration by painting" reported by Michael. Here are the results for the process gimp-2.4.exe with painting while toggleing: Process Name 64-bit Total % Timer samples win32k.sys 27,12 2856 ntkrnlpa.exe 19,33 1950 liblcms-1.dll 15,07 1633 gimp-2.4.exe 11,43 1238 LIBGOBJECT-2.0-0.DLL 4,15 450 LIBGLIB-2.0-0.DLL 4,11 445 ntdll.dll 3,41 369 LIBGDK-WIN32-2.0-0.DLL 2,35 255 LIBCAIRO-2.DLL 1,71 185 GDI32.DLL 1,56 169 LIBGTK-WIN32-2.0-0.DLL 1,4 152 MSVCRT.DLL 1,19 129 nv4_disp.dll 1,11 113 KERNEL32.DLL 1,04 113 LIBPANGO-1.0-0.DLL 0,84 91 hal.dll 0,67 67 USER32.DLL 0,46 50 LIBGTHREAD-2.0-0.DLL 0,37 40 NVIEW.DLL 0,32 35 nv4_mini.sys 0,23 24 watchdog.sys 0,18 17 LIBPANGOCAIRO-1.0-0.DLL 0,18 20 UXTHEME.DLL 0,14 15 LIBPANGOWIN32-1.0-0.DLL 0,12 13 INTL.DLL 0,09 10 serial.sys 0,06 6 vsdatant.sys 0,05 1 LIBGIMPWIDGETS-2.0-0.DLL0,05 5 i8042prt.sys 0,05 5 MSCTF.DLL 0,04 4 VIDEOPRT.SYS 0,03 3 USP10.DLL 0,03 3 USBPORT.SYS 0,03 1 mouclass.sys 0,03 3 avipbb.sys 0,03 3 LIBWIMP.DLL 0,02 2 LIBGIMPMATH-2.0-0.DLL 0,02 2 libcdisplay_lcms.dll 0,02 2 irsir.sys 0,02 1 rdbss.sys 0,01 1 PSAPI.DLL 0,01 1 nvatabus.sys 0,01 1 LIBGIMPCOLOR-2.0-0.DLL 0,01 1 CTAGENT.DLL 0,01 1 Here are the results for the process gimp-2.4.exe without painting while toggleing: Process Name 64-bit Total % Timer samples win32k.sys 39,61 4207 ntkrnlpa.exe 25,68 2563 liblcms-1.dll 6,59 708 gimp-2.4.exe 3,88 417 ntdll.dll 2,92 314 GDI32.DLL 1,65 177 LIBGDK-WIN32-2.0-0.DLL 1,2 129 hal.dll 0,76 68 LIBGLIB-2.0-0.DLL 0,7 75 LIBGOBJECT-2.0-0.DLL 0,52 56 LIBCAIRO-2.DLL 0,24 26 nv4_mini.sys 0,23 22 nv4_disp.dll 0,22 21 MSVCRT.DLL 0,2 22 LIBGTK-WIN32-2.0-0.DLL 0,16 17 LIBGTHREAD-2.0-0.DLL 0,15 16 KERNEL32.DLL 0,09 10 USER32.DLL 0,08 9 serial.sys 0,05 5 LIBGIMPWIDGETS-2.0-0.DLL0,05 5 watchdog.sys 0,04 4 LIBPANGO-1.0-0.DLL 0,02 2 avipbb.sys 0,02 2 USBPORT.SYS 0,01 1 mrxsmb.sys 0,01 1 LIBPANGOWIN32-1.0-0.DLL 0,01 1 irsir.sys 0,01 1 i8042prt.sys 0,01 1 I hope that will help...?
This profiling data is close to being completely useless. We need to know in which function the time is spent, not in which library.
Okay. The tool delivers more detailed data for each module involved. But that's very complex and i'm not able to evaluate if and what possibly is of interest. example: CS:EIP Symbol + Offset Thread ID 64-bit Total % Timer samples 0x672d2430 g_hash_table_lookup 0.08 9 0x672d2473 g_hash_table_lookup+67 1796 0.03 3 0x672d245e g_hash_table_lookup+46 1796 0.03 3 0x672d24a9 g_hash_table_lookup+121 1796 0.01 1 0x672d248f g_hash_table_lookup+95 1796 0.01 1 0x672d244f g_hash_table_lookup+31 1796 0.01 1 0x672f6ad0 g_slice_alloc 0.07 8 0x672f6c9b g_slice_alloc+459 1796 0.04 4 0x672f703f g_slice_alloc+1391 1796 0.01 1 0x672f6cc7 g_slice_alloc+503 1796 0.01 1 0x672f6caf g_slice_alloc+479 1796 0.01 1 0x672f6b0f g_slice_alloc+63 1796 0.01 1 0x672f7bd0 g_slice_free1 0.05 5 0x672f7def g_slice_free1+543 1796 0.01 1 0x672f7dcf g_slice_free1+511 1796 0.01 1 0x672f7cea g_slice_free1+282 1796 0.01 1 0x672f7cc5 g_slice_free1+245 1796 0.01 1 0x672f7bd0 g_slice_free1+0 1796 0.01 1 0x672d2e50 g_hash_table_remove 0.04 4 0x672d2ee9 g_hash_table_remove+153 1796 0.03 3 0x672d2f08 g_hash_table_remove+184 1796 0.01 1 4 functions, 17 instructions, Total: 26 samples, 34.67% of samples in the module, 0.24% of total session samples I did what i could. I'm sorry that i couldn't help.
This excerpt doesn't help us. But if you could attach the detailed profiling data here, we could probably use it.
The fact that the code seems to be spending almost twice as much time in liblcms as in the gimp executable is perhaps meaningful -- and the ratio seems to go down while painting.
To follow up on that, you could try turning off color management in the Preferences->Color Management tab, to see if it makes any difference.
It is not at all surprising that most time is spent in lcms as the display color correction is the most expensive part of the code path that is being executed when the display is updated.
It would be interesting to know if changing the priority of the idle handler in app/core/gimpprojection.c makes any difference. Perhaps try to change line 549 and use G_PRIORITY_DEFAULT_IDLE or even G_PRIORITY_HIGH_IDLE instead of G_PRIORITY_LOW.
I had some problems in building up a working environment for compiling GIMP (minGW, msys, etc.) with suitable versions of libraries and so on, but in the end with success. First i've compiled the 2.4.2 unchanged for comparison purposes to the Windows binary downloadable at gimp.org. After that I've changed G_PRIORITY_LOW to G_PRIORITY_HIGH_IDLE in line 549 of gimpprojection.c. With this change the toggleing is as fast (maybe faster) as in GIMP 2.2.17
I will have a look at adjusting the idle priorities then. Looks like we lowered them to a point where other sources in glib and gtk+ get higher priority than the display update.
Michael, thanks for your help with this. Please check if G_PRIORITY_DEFAULT_IDLE is good enough. I have now applied this change to both branches: 2007-11-29 Sven Neumann <sven@gimp.org> * app/core/gimpprojection.c (gimp_projection_idle_render_init): raise the priority of the idle renderer to G_PRIORITY_DEFAULT_IDLE. Should fix bug #499150.
Unfortunately G_PRIORITY_DEFAULT_IDLE isn't good at all. There's no difference to having compiled with G_PRIORITY_LOW To be shure i've compiled it a second time with G_PRIORITY_DEFAULT_IDLE (after "make clean" and deleting everything from source-directory) It's really as slow as with G_PRIORITY_LOW Same procedure for an anew compiling with G_PRIORITY_HIGH_IDLE. And indeed the result is spectacular fast.
Shouldn't hurt to raise it to G_PRIORITY_HIGH_IDLE. I have now done this in both branches: 2007-11-30 Sven Neumann <sven@gimp.org> * app/core/gimpprojection.c (gimp_projection_idle_render_init): raised the idle renderer priority even higher (bug #499150).