GNOME Bugzilla – Bug 705645
Canvas re-draw unbelievably slow for OSX native
Last modified: 2018-05-24 13:49:16 UTC
Open a large-ish image (4k+ x 3k+). Apply a color curve/levels/toggle-layer-visibility, and the canvas redraws... very... slowly... It can take up to 15-20 seconds for the canvas to fully reflect the operation (toggling visibility for instance). Same for any other operations that affect the view on the canvas. Zooming way out alleviates the time required to finish the operation (zoom out to 10%, and toggle a layer visiblity, and it's quick). A screencast of the problem taking place: http://www.youtube.com/watch?v=dxLlOJY7ZJs I'm using the most recent build by Partha (2.8.6) OSX 10.7.5 (Macbook Air) 4GB RAM
Couldn't attach trace file (too large). Find it here: https://www.dropbox.com/s/ndnxmp15zngf280/Instruments2.trace.zip
Yes this sucks a lot. I pushed some code to master that fixes it completely, but it's probably not easily mergable to 2.8, haven't checked yet.
I just wanted to confirm the same exact slow redrawing, only on Linux and built with source fetched from git. Steps (with git-fetched source) 1: create/import large-ish image in GIMP (my working image was ~4000x7000) 2: add layer(s) plus content 3: toggle a layer's visibility The layers will update just as in Pat's video, and during the process GIMP will completely hang up on one CPU core while also loading up the videocard. If you minimize/maximize the GIMP window, it'll stay blank until the redrawing job is done. System: x86_64 Gentoo Linux (kernel 3.9.9-gentoo with nvidia-drivers 325.15) gimp -v: GIMP 2.9.1, GEGL 0.3.0, GLib 2.36.4, GdkPixbuf 2.28.2, GTK+ 2.24.20, Pango 1.34.1, Fontconfig 2.10.93, Cairo 1.12.16 GIMP at commit cd4d5e6d32169e0d642010b992ad401244db354d
If this happens on linux, then you somehow broke something in your stack which makes displaying the rendered image slow. This should not happen unless your machine is *very* slow.
My best guess is that your cairo is not built correctly.
*** Bug 683373 has been marked as a duplicate of this bug. ***
Just an update leading up to LGM... Partha was kind enough to build me a new GIMP from master today (version on his build is 2.9.1). It appears the problem is still there.
(In reply to comment #2) > Yes this sucks a lot. I pushed some code to master that fixes it completely, > but it's probably not easily mergable to 2.8, haven't checked yet. If it's in master, not sure if it fixed the problem...
I'm sure that my change in master made it almost infinitely faster :) Who knows what has happened since, I haven't tried on OSX in a while, will check...
Not sure if relevant at that stage, but this bug is still happening on the 2.8.14 and Lisanet 2.8.15 under a fresh Yosemite install on a quad core Ivy Bridge CPU...
Looks like I can reproduce the behavior from the YouTube video in comment 1 on OS X 10.9, Core 2 Duo CPU with gimp master.
We did a kind of non-scientific comparison between an OS X and Linux machine (with comparable CPUs) with gimp master and the Linux machine rendered the preview twice as fast.
"twice"? That would be a fixed version on OSX. The original problem made it like 10% as fast as the Linux version.
It's certainly not as slow as in the video -- but it is noticeably slower than on Linux. Shouldn't it be about as fast? My next step is to isolate the actual computation time of the pixels of the preview and see what share this is of the render time of the projection.
Yes it should be just as fast. My theory is that it can't really be the projection construction, because that's pure GEGL and I don't see any reason why it should preform poorer on a comparable Intel chip on the Mac. I guess there is some roundtrip to some Mac API involved, and that makes it wait for something. Putting the pixels to screen has been optimized by the masters of cairo themselves (GimpDisplayXfer), maybe that is simply not as good on OSX due to whatever cairo/gdk/osx interaction.
I agree that the projection code should not perform any poorer. GIMP triggers the gdk_window_process_updates which triggers [NSView displayIfNeeded]. I am wondering if that's somehow hampering performance. By first verifying that the performance of the projection code is indeed not the problem, we know for sure where to look further.
https://bugzilla.gnome.org/show_bug.cgi?id=708579#c6 suggests the color management is applied twice on OSX, one in GIMP and one by the system, that could be particularly expensive and perhaps it would help to build a patched cairo that tells OSX the display color profile has been already applied.
I have briefly seen the OS X color conversion show up in the profiles on my Core Duo machine; but not on the Core i7 machine I was using yesterday. When the OS X color conversion introduces a performance penalty, it does usually show up in the profiles as a call below CoreGraphics primitives.
(In reply to comment #18) > I have briefly seen the OS X color conversion show up in the profiles on my > Core Duo machine; but not on the Core i7 machine I was using yesterday. When > the OS X color conversion introduces a performance penalty, it does usually > show up in the profiles as a call below CoreGraphics primitives. Ok, there is another report that suggests drawing the rulers is expensive on OSX and Windows, that would mean probably painting text glyphs, so another thing to consider is hiding rulers. OTOH, this bug report is for GIMP 2.8 that used limitedly GEGL, so I think that GEGL has an impact similar to Linux
I actually believe now that the problem as indicated in the opening comment of the bug is not occurring (at least not on my Macs). I compared the performance again between my MacBook Air (quad-core Ivy Bridge) and my quad-core Core i7 Linux desktop, both running GIMP master The desktop is slightly faster. The MacBook really is no where as slow as is shown in the YouTube videos. One thing that is still puzzling me is that Mitch has told me that showing an image layer on top of a white layer should be completely instant, because it is like that on his 2 to 3 year old laptop. However, both on my MacBook and Desktop machine this display is not instant and you can still see the tiling effect. From what I figure on my Mac, the computation for this simply takes long enough for the tiling effect to kick in. Mitch: if it appears we both come to FOSDEM in a month from now, we could do some real-life comparisons :) I am not really satisfied with the fact that the tiling effect kicks in when showing just a 4500x3012 image layer on a laptop bought this year. In order to analyze this, it would probably be interesting to write some kind of "GIMP benchmark" that runs a number of common operations on a couple of test images without showing the GUI. This would also be a useful tool to put through a profiler. Or perhaps something like this exists already?
Which is what I suspected: the issue is fixed on master (more or less, as you correctly observed), but it still exists on 2.8, and is entirely unrelated to GEGL.
To confirm this, I built gimp 2.8 on my Mac. Gives exactly the behavior as shown in the opening comment, unbelievably slow. So this is indeed fixed in master.
*** Bug 742994 has been marked as a duplicate of this bug. ***
*** Bug 741755 has been marked as a duplicate of this bug. ***
*** Bug 764227 has been marked as a duplicate of this bug. ***
The slowness is observed also within progress bars. If the progress bar is visible, it takes more time to complete versus when the progress bar is not visible (window dragged partially outside visible area to hide the progress bar). For instance image export takes 10-20x more time compared to the case when there is no need to update the progress bar. Using gimp 2.8.16 on OS X 10.11.4
*** Bug 759029 has been marked as a duplicate of this bug. ***
Hi, I have the same issue on my MacBooKPro middle 2010 with ElCapitan and Gimp 2.8.20. I can try on my Windows 7 x64 partition but this issue is not present, apply filters, apply a color curve/levels/toggle-layer-visibility is faster then OSX. I hope it will be solved as soon as possible because it's very frustrating. p.s.: my thoughts, Is not possible to use the video card dedicated (in my case Nvidia gt330M) to improve the performance? Maybe is already so, but I have an impression that the video card dedicated is not works in Gimp. Best regards Faio
Maybe this is related to bug 778966 - if redraws of the UI would be super-slow on this platform if a pixbuf-based theme is used.
I think this an only OSX problem. I did the same things on Windows and Debian, the latter was on a virtual machine and Gimp worked fast. I hope that problem will be solved in next update. Fabio
Does this still happen with 2.8.22? The fix done for bug 778966 might have improved performance a bit.
I just tried the v2.8.22, still exactly the same issue, same speed :( However, with the McGimp 2.9.5, it works absolutely perfectly...
(In reply to Michael Schumacher from comment #31) > Does this still happen with 2.8.22? The fix done for bug 778966 might have > improved performance a bit. The fix for 778966 only improved performance for a very specific case. This bug (705645) concerns a different kind of problem (a more general problem). The changes made in 2-9 to fix this were not backmerged to 2-8.
Disabling color management in Gimp settings improved speed A LOT for me (2.8.22).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/490.