macOS latency and performance

[learmj]

Hi there. I've used RT for years on Linux. I think it's a fantastic tool that you have all developed and maintain. I'd be lost without it. I made the switch from Linux to a Mac last week and had a it of a shock when I tried using RT on my new macbook pro 16 (2019). It works, but there is so much latency (eg dragging sliders or moving curves, and the image taking a long time to update afterwards). It makes it pretty much unusable for me, which I'm really sad about. My first question is - is this normal for RT on mac os? The UI looks slightly odd too in that the fonts seem slightly blurry and out of alignment, so I am thinking there is something missing in my env. This was with the the latest pre-built 5.7 from your website. I then went to rawpedia, installed the dependencies using homebrew (making sure that my clang had support for openmp - which it does - I can compile a test program), compiled RT from source (5.7 release from git) but that build of RT doesn't run, and crashes with SIGABRT.

So I am wondering:

• If there is something in my env which makes the pre-built image look less than crisp?
• If the latency / lag is expected on mac os - Catalina in my case?
• If the instructions on rawpedia for building on mac os are up to date, and for building on Catalina?

The crash in my own build seems to be because of this:

(rawtherapee-bin:687): GLib-GObject-WARNING **: 08:18:30.265: invalid cast from 'GtkMenuBar' to 'GtkWindow'

(rawtherapee-bin:687): Gtk-CRITICAL **: 08:18:30.265: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed

(rawtherapee-bin:687): Gtk-WARNING **: 08:18:32.744: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg.
This may indicate that pixbuf loaders or the mime database could not be found.

(rawtherapee-bin:687): Gtk-WARNING **: 08:18:33.747: Could not find the icon 'list-remove-symbolic-ltr'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
    http://icon-theme.freedesktop.org/releases
**
Gtk:ERROR:../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognised image file format (gdk-pixbuf-error-quark, 3)
Bail out! Gtk:ERROR:../gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognised image file format (gdk-pixbuf-error-quark, 3)
zsh: abort      ./RawTherapee.app/Contents/MacOS/rawtherapee

..but I have hicolor installed with homebrew, so I'm not sure what this is telling me.

If there was a way that I could help you try to improve RT on mac os, then I'd be very grateful. If you were able to clarify the above points for me, it would help me understand if I can stay with RT on my mac.

Many thanks, and thanks again for developing RT. I do not want to lose it. Regards.

[Beep6581]

Maybe @Benitoite could answer a few of those questions.

[blj86]

Hello I would like to chime in a bit here as I too have been having this issue. I have been discussing it with heckflosse and Morgan Hardwood on discuss trying to gather more information before writing a report.

I have this issue on my 2019 21.5" 4k iMac Mojave 10.14.6. Through some testing I have narrowed it down to something going on with the Gui. The rendering of the actual preview is quite snappy still. The issue also occurs when using Resize which does not update the preview window.

Through some testing I was able to narrow it down to the 4k HDPI resolutions of my iMac. If I switch the iMac to Low Resolution mode all the Gui issues stop and the application runs fine.

The issue does not seem to be GTK+ project related as through testing of both darktable (gtk+3) and gimp (gtk+2) none of these issues exist.

Here are some videos demonstrating the issue. The archive is my original screencaptures the .mp4 was placed there by either heckflosse or Morgan Hardwood not sure which.

https://filebin.net/fmtm0yy3b8xb8gqn

I still have some more test to run a little later and will update with the results here. Need to check by using a non scaled 4k (Native) resolution as well as with the css themes removed to try and narrow down further.

Edit: I should note I am using version 5.7 compiled with MacPorts clang 9.0 using DPROC_TARGET_NUMBER="2". I was going to use a dev build but at the time I built last night dev would not compile due to a code error in rtengine.

Update: Running at a non scaled resolution in my case 4096x2304. At this resolution everything is so tiny I had to really up the font to read anything. Sliders, curves, and scrolling through modules was still all janked up. The Sliders, curves were not as bad but they still had some lag. Scrolling was even worse. Also rendering of the preview at this resolution was about 1/2 a second slower which is totally expected and normal in my eyes. But we still have a Gui issue.

Also ran with all css themes removed which all be it ugly was still worth the look. This made no change the GUI in the HDPI resolutions is all messed up like in the videos still.

Not sure what the cause can be since other Gtk applications do not suffer from this hopefully this information will be helpful in tracking down a potential solution in the future.

If you need anything else tested feel free to let me know I would be more then happy to.

[Beep6581]

Hi @blj86 , I am Morgan Hardwood from the forum. Let's continue troubleshooting here instead of the forum.

One more test:

1. Save the following to a file called reset-GTK3-20_.css inside RawTherapee's themes folder:

   * {
   all: unset;
   }

2. Run RawTherapee, go to Preferences and select the new reset theme.
3. Close and restart RawTherapee.
4. See if scrolling the tool panel is any faster now.

The reset theme should look horrible, exactly like this:

[blj86]

@Beep6581 I ran the reset theme like suggested the the scrolling is still very laggy. Seems to be the same as when normal themes are in use.

[Beep6581]

So we can be fairly confident it has nothing to do with themes or CSS effects.

The next thing to look at would be whether there are any calculations being performed by our code (as opposed to standard GTK+ code), maybe as a result of the pseudo-HiDPI code. That's something @Hombre57 could advise us about, where to look.

@blj86 @stdbull do you get the same poor performance when scrolling the tool panel in @agriggio 's fork of RawTherapee called ART? https://discuss.pixls.us/t/art-the-software-news/14334

[learmj]

Hi. Thanks for taking the time to look into this further, for the additional inputs @blj86 and for consolidating the investigation into this issue here. I'm more than happy to try new things, but first I need to try and understand why my RT build from git crashes when the same macOS environment seems fine to run the dimg downloaded from the RT website. Do the traces I posted above sound familiar? Once I sort that out and understand the problem, I'd be happy to build/install ART and take a look to see how it performs on my system. Are the build instructions currently on rawpedia for building for macOS, exactly applicable for Catalina? Given that the pre-built RawTherapee_OSX_10.9_64_5.7.zip image available from the RT website opens fine for me on Catalina, I am thinking that there is something missing when I compile the same RT source myself. I would like to fix that. Any pointers or ideas about what could be going wrong would be greatly appreciated.

[blj86]

@stdbull are you using Macports or Homebrew? I found Homebrew rather unreliable for building a operational RT. Macports always works for me but you do need to tweak the wiki guide slightly.

I will also give ART a test to see if same issues are present. Currently working but will build it later tonight and post a update.

[learmj]

@blj86 I used homebrew. It seems sufficient to build the dependencies for the pre-built RT image from the RT website (although fonts look strange and fuzzy - and very small! - almost like the anti-aliasing has gone weird). Interestingly, I tried to run the RT app that I built without copying all the dimg into /Applications. By doing this I can get a UI in which fonts looks crisp and clear, but nothing works - no buttons, no boxs or dialogues, etc (not surprising as it is essentially an incomplete install). But there is some text and it certainly appears as though what I've built RT against on my system makes it look visually correct compared to how the pre-built looks when running on the same system. I don't know where it's expecting to load /org/gtk/libgtk/icons/16x16/status/image-missing.png from. This seems the cause of my crash. Where do yo have this file on your installation? I see it in two theme directories. I don't what governs RT to look for this file and in which location(s).

[blj86]

@stdbull sorry for delay. I don't want to clog this issue with compiling discussion. I had similar issues with Homebrew. For some reason when making the application bundle resources are missing. When checking the directories of Homebrew they were missing there as well. Hence my Macports suggestion. I think some packages in Homebrew are broken.

If you have more compile questions you can message me on discuss.pixls.us there I am known as blj.

[learmj]

No problem @blj86

I don't want to clog this issue with compiling discussion.

Sure, I agree with that. I'll get myself fixed up. We can continue the performance discussions and investigations here.

[Hombre57]

@Beep6581 The pseudo-HiDPI patch doesn't introduce any heavy calculation regarding the GUI (not even slightly), it only force Gtk to use a non-scaled resolution mode.

Things looks like RT was run either trough GDB, or a sandbox, or with debug version of the dependencies. Could you attache your AboutThisBuild.txt file please ? Do you use the same Gtk version for RT, DT and Gimp ?

@stdbull

I don't know where it's expecting to load /org/gtk/libgtk/icons/16x16/status/image-missing.png from. This seems the cause of my crash. Where do yo have this file on your installation? I see it in two theme directories. I don't what governs RT to look for this file and in which location(s).

RT doesn't look for this png file but Gtk does, when it fail to load a Gtk icon (e.g. the one for the drop-down arrow in your screen recording is not provided by RT). I'd check that RT is correctly installed first with correct dependencies before looking at RT's code. @Benitoite could probably help you on this, I'm not using macOS.

[Hombre57]

In fact, the missing icon is defined in RT's code, but pan-down-symbolic should be part of the standard Gtk icon theme.

[blj86]

@Hombre57 I am not sure what version of GTK3 darktable is built with I use one of their prebuilt. As far as RT all dependencies in my build are release and I built RT as release. All my deps are the latest from Macports. This issue also happens with the pre built 5.6 and 5.7.

So for GTK3 that is version 3.24.12.

I will post my about this build when I get home later.

[Hombre57]

@blj86 When you'll be able to run RT, could you run macOS' Activity monitor and see if RT and/or other process loads the processor ?

[blj86]

@Hombre57 Sure.

Here is the about this build file: AboutThisBuild.txt

Not sure exactly how MacOS activity monitor reads as I am personally new to MacOS however with that said.

When in a HDPI resolution RT idles about 30% CPU when manipulating the Gui it spikes to over 400%.

When using the "secret handshake in settings" and going to a Low resolution mode RT idles about 11% and when making edits spikes in the range of 88% I think I saw a glimpse of 143% but only for a smidge.

In low resolution mode everything is smooth as butter but in HDPI modes it is like the video really janky.

I also did a quick test with darktable without openCL enabled while in HDPI resolution to place us on an even playing field for comparison. The CPU spikes to about 280% the GUI still smooth and responsive.

Update: @Beep6581 I also did a build of art as suggested same issues are present with that application.

[Hombre57]

@blj86 Thanks for the numbers, however if they can go above 100%, they become meaningless for me. What is the range exactly ?

Since you can build RT yourself, I'll provide a patch to disable HiDPI support and we'll see if it's the culprit.

[blj86]

Yea they are doing something funky with their monitor. I was like how is this even possible :smile: Later after work I will install HTop and try that. If you provide a patch will be more then happy to test.

[Hombre57]

@blj86 In fact, disabling pseudo-HiDPI support has already been rerquested and there's the PseudoHiDPISupport option value (in the options file) that you can set off (no GUI). Could you please try that first ?

[blj86]

@Hombre57 I never used the pseudo hdpi option in the GUI is this a different setting in the options file? If so sure thing will give it a shot.

[Hombre57]

@blj86 Yes, that's a setting that has no GUI. However it's false by default, so you should have blurry icons when used used on a HiDPI resolution.

[Hombre57]

@blj86 Erm... Sorry, there's a GUI for this parameter, don't know how I managed to overlook that thing that I did myself. So if it's off, then I don't have a clue of the reason of the lag.

[blj86]

@Hombre57 understandable. This is indeed really weird of a issue. As it only happens with RT but also it seems only on MacOS. You would think it would effect all platforms at 4k resolutions.

I am at a loss as well. I can program but know nothing about gtk and not near knowledgeable enough to know the raw processing maths. But I do wonder if there is some odd MacOS specific optimization issue somewhere that somehow is effecting the GUI and becomes pronounced with the heavier load of 4k.

I will still check CPU usage with HTop later not sure what else I could do.

[Hombre57]

@blj86 Other macOS user are running RT fine on Mojave, don't know for Catalina.

Have you tried to enable the HiDPI support in the Preferences window ?

Is there any particular disk or network activity while running RT idle (e.g. to look for missing icons or exploring the storages) ?

Is it possible to build RT with gcc (or get it prebuilt) ?

Could you paste a screenshot of your system display scaling settings where RT lags the most ?

[blj86]

@Hombre57 Well this is interesting. Ran HTop. There were some occasional spikes to 100% on all cores but only if jerking the sliders around. When moving them normally CPU stayed under 100% in HDPI mode. Psudo HDPI mode performed the same as if I had it disabled. Right now however there is still a very tiny amount of lag it is no where like what it was before. The application is totally usable with or without Psudo HDPI mode on.

The laggy scrolling still happens but only if I use the Magic Mouse to scroll if I drag the scroll bar it is smooth. Moving the sliders in HDPI mode only lag very minutely not bread crumbing (trailing behind by inches) anymore. So the mouse is probably causing the scroll issues in the modules pane which is odd but possible I guess.

The biggest difference is they fixed the bug that would not let me compile the dev tree so now I am running the dev tree. Also before Psudo HDPI mode was actually not doing anything now it actually makes things bigger.

Speaking of the Idle test showed no HDD or Network activity.

So apparently the dev tree fixed something somewhere that was acting up in the 5.7 release tag. Granted I still have no lens corrections for some reason but it seems that building dev made the software usable with minor slider widget lag.

Now I am even more confused because before it was totally unusable.

[Hombre57]

@blj86 I don't know what Magic Mouse is, would be nice if you could test with Standard Mouse instead 🙂 .

Moving the sliders in HDPI mode only lag very minutely not bread crumbing (trailing behind by inches) anymore

If I don't click on the center of the slider's knob, like just on left or right side, it move the slider but slowed down. It seem to be a Gtk features. Is this what you're experiencing too here ?

[learmj]

Hi again. My build issues aside (looks like a packaging issue - not sure what/why yet but I'm missing loads of files in the dimg even though I have them installed with homebrew. For example the entire Adwaita theme, various dylibs and DSOs in Frameworks like libxml2, libpixbuf, libz, etc). Anyway, I see some unexpected (for me) behaviour in gimp. Open it. File new window. Default canvas. Colours -> Saturation. Play with the scale slider. I think there seems to be a GTK 'feature' where the distance you drag the mouse is greater than the distance that the slider moves. It almost looks 'elastic'. This is consistent with manipulating other sliders, eg in the toolbox (brush size and so-on). I think it looks fine in that there is no lag between mouse motion and movement of the slider. Maybe this is a clue for what should be expected in RT..? I don't see the same behaviour in RT when moving sliders. It seems like the movement between mouse and slider is linear rather the 'elastic'. Hope you are able to follow what I'm trying to explain :-)

[blj86]

@Hombre57 Not sure. The apple mouse does not have a wheel. Scrolling is done with touch like a phone. I know darktable had some weird issue with it when masking they had to fix. But again I don't get the scroll lag in low resolution mode. So still odd. At this point I am beginning to think that 4k display + RT on Mac is just not playing nice on Mac. One way to get improvement in the GUI lag is to make the RT window smaller instead of stretched across the whole screen. Starting to think my machine may just be getting overtaxed by RT when I am in a HDPI resolution.

[Hombre57]

@blj86 First thing to try is to disable OpenMP when building RT (there's a CMAKE switch), processing the preview will be slow but you'll see if the remaining core will be available for the GUI, or if the lag still persist.

[Hombre57]

For the touch emulation, there was some work done when panning the file browser, but I'm not sure for the tools' tab.

[Krijger]

@stdbull also have a look at #5550 for working together on a Mac OS build

[learmj]

@Krijger Thank you. I'll keep an eye on that one. I'd be super interested to know the baseline (pkg versions, home-brew/macports, etc) that you use for the builds. I've spent a couple of hours on my issues over the last few days. I realised I wasn't using the home-brew g++ (but I was using it's gcc) so falling back to the Apple C compiler (no openmp, etc). Sigh... Once I switched to correctly using the home-brew compilers, I end up with many linker errors relating to some Cairo, glib and gtk routines. I've not debugged it much further but I will try to spend some time on it this week. I'd be super interested to hear from anyone who has a working RT build on Catalina using Homebrew. Cheers.

[Krijger]

@stdbull you're welcome to check it out and see about those questions. I must confess I hardly know anything about this landscape, but I for instance needed to know where the Mac OS build agent has libiconv installed and you can see here (https://github.com/Krijger/RawTherapee/commit/6dfd1e1ac5793b37544db5ee5a83da97977fdb2b) how I did that with the result https://github.com/Krijger/RawTherapee/commit/6dfd1e1ac5793b37544db5ee5a83da97977fdb2b/checks?check_suite_id=348074570, so you can do similar experiments yourself

[Krijger]

I fear I need help on #5550 , maybe something @stdbull or @blj86 could have a look at? - sorry for the noise, but I can't address you from the other issue

[learmj]

The crash in #5550 looks similar to what I see. I'm now confident that my build and link is happening as intended (successfully using llvm and clang-9) but there are things going wrong at the install phase when the bundle is created. Looks like some gtk3 files are being searched for that don't exist. Same for some dylibs and other support libraries/binaries. The locations being referenced by the installer to find files appear to not be correct for my system, and various files/dirs don't exist. What I see in the attached log directly explains the missing files and dirs in the resultant ding file. My failure to load...

image-missing.png: Unrecognised image file format (gdk-pixbuf-error-quark, 3)

...is more than likely due to the pixuff loader and/or cache being missing in addition to not being able to translate the mime type of the file and map it to the loader, etc.

I'll try to spend some time figuring out why the wrong locations are being used by the installed this week. I don't understand how RT knows where to look for gtk+2 and gtk+3 files and why it would pick gtk+3 to look for gdk-pixbuf in. For example:

ls: /usr/local/Cellar/gtk+3/3.24.12_1/lib/gdk-pixbuf-2.0: No such file or directory

But these exist:

/usr/local/lib/gdk-pixbuf-2.0 /usr/local/Cellar/gdk-pixbuf/2.40.0/include/gdk-pixbuf-2.0 /usr/local/Cellar/gdk-pixbuf/2.40.0/lib/gdk-pixbuf-2.0 /usr/local/Cellar/librsvg/2.46.4/lib/gdk-pixbuf-2.0

install.log

[Krijger]

In the linker options in line https://github.com/Beep6581/RawTherapee/blob/0f3bddbe4f7ad619849a281a2fd9dc294a178d63/.github/workflows/main.yml#L42 I have -L/usr/local/lib, which I guess would lead to /usr/local/lib/gdk-pixbuf-2.0 being picked. I will throw in a ls /usr/local/lib in the build to be able to see what is in there.

[Krijger]

By the way, let's move all build-related discussion to #5550

[learmj]

Agreed. Let's keep this one to investigate / discuss UI responsiveness.

[learmj]

Hi. Probably not too much of a surprise, but building @Krijger ci-macos branch at the current tip 24deb0a78 (#5557) has the same lag and performance issues when running on Catalina as discussed and described previously here. https://github.com/Krijger/RawTherapee/commit/24deb0a788cbffb444e2058dadfee4d07f03a8bc The pre-built available from the CI build is exactly the same. Hopefully we can still work on figuring out exactly what's wrong.

[heckflosse]

If we could get donations to buy a macbook pro 16 for testing, I would be able to chime in...

[Hombre57]

Same for getting a 4k monitor to test the HiPDI features... 😉

[learmj]

If I win the lottery I would gladly donate whatever it took to give something substantial back to the fantastic team that developed RT. Until then, all I can offer to debug is my low level embedded skills (not much use here - but I'm no stranger to gdb, etc) and my enthusiasm :-) If you have any ideas of how to try and drill down into this problem, I'd be happy to try and help. Cheers.

[Krijger]

Note that it's easy to branch of for a quick "debug" instead of "release" build, for analysis of the logs

[Hombre57]

@stdbull Could you make the test I asked for to @blj86 earlier please ?

First thing to try is to disable OpenMP when building RT (there's a CMAKE switch), processing the preview will be slow but you'll see if the remaining core will be available for the GUI, or if the lag still persist.

And I'd add one test with Release build, one with Debug build.

[learmj]

@Hombre57 Sorry for the delay. I added -DOPTION_OMP="OFF" to the cmake line and also removed the other OpenMP_xxx options. Configure runs fine and there is no sign of openmp being picked up. But the build fails compiling rtexif/CMakeFiles/rtexif.dir/rtexif.cc.o complaining of being unable to find tiff.h. I put the OpenMP_xxx options back in and re-ran configure and make. Make understandable told me:

CMake Warning: Manually-specified variables were not used by the project:

OpenMP_CXX_FLAGS
OpenMP_C_FLAGS
OpenMP_C_LIB_NAMES
OpenMP_libomp_LIBRARY

But the end result was the same. Seems it is not possible to compile with openomp disabled.

[heckflosse]

@stdbull

Seems it is not possible to compile with openomp disabled.

Strange, as it is possible to build RT on Windows with clang which does not support OpenMp at all ...

[heckflosse]

@stdbull

But the build fails compiling rtexif/CMakeFiles/rtexif.dir/rtexif.cc.o complaining of being unable to find tiff.h.

please post the log

[Benitoite]

@Krijger @stdbull Have you tried to add -I/usr/local/include to your -DCMAKE_CXX_FLAGS and -DCMAKE_C_FLAGS ?

Also I am on AppleClang11 (Catalina), no problems with OpenMP...

What I am not using is any package manager, so I have no clue what all else is going on there.

[learmj]

Sorry for the delay in trying things. I've not had much time recently. What source tree am I best to be compiling? I am currently on the ci-macos branch. Am I best to switch to something different to try this (hopefully later today)? By 'no problems with OpenMP' do you mean you can build without, or you don't observe the latency issues?

On Mon, 23 Dec 2019, 10:57 Benitoite, notifications@github.com wrote:

@Krijger https://github.com/Krijger @stdbull https://github.com/stdbull Have you tried to add -I/usr/local/include to your -DCMAKE_CXX_FLAGS and -DCMAKE_C_FLAGS ?

Also I am on AppleClang11 (Catalina), no problems with OpenMP...

What I am not using is any package manager, so I have no clue what all else is going on there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Beep6581/RawTherapee/issues/5552?email_source=notifications&email_token=ACM6NAJR63JAUI722FGWKVTQ2CKP5A5CNFSM4JUT5SI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHQ3YJI#issuecomment-568441893, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACM6NANSUOXZBVZS5YIFHDDQ2CKP5ANCNFSM4JUT5SIQ .

[learmj]

I synced to the tip of @Krijger 's ci-macos branch and added -I/usr/local/include to MAKE_CXX_FLAGS and CMAKE_C_FLAGS and built without OpenMP support. I totally missed that earlier - thanks @Benitoite . I also used the Apple clang for all tools. With a Release build, the observed latency with moving sliders, dragging curves etc is exactly the same as when compiling with OpenMP as previously described (Release). There is no perceived difference in the UI behaviour. In terms of CPU utilisation, htop shows three cores running at approx 50%, some others at zero, a couple at approx 20 when dragging a curve control up and down. Preview seems to redraw at the same speed as when compiled with OpenMP. From what I can tell, there is no real difference compiling with OpenMP or without.

The very interesting thing I found is compiling a Debug build with OpenMP disabled. UI performance is much improved! Dragging the same sliders, moving curve controls and navigating the UI in the same way as before is significantly better! Dragging scroll bars in menus is not snappy, but it is a marked improvement over a Release build.

I then tried a Debug build with OpenMP enabled and using the llvm tools for clang, clang++, ar and ranlib. Behaviour in the UI feels the same as the Debug build without OpenMP, but this time, htop shows all cores hitting 100% every so often and definitely more CPU activity / usage (as you'd expect). But strangely, the overall experience does not seem improved with Debug and OpenMP.

I'm not sure if this makes sense, but clearly a Debug build exhibits far improved responsiveness in the UI.

[Benitoite]

In the UI ok but how is the performance with highly parallelized tasks?

On Dec 23, 2019, at 2:00 PM, stdbull notifications@github.com wrote:

 I synced to the tip of @Krijger 's ci-macos branch and added -I/usr/local/include to MAKE_CXX_FLAGS and CMAKE_C_FLAGS and built without OpenMP support. I totally missed that earlier - thanks @Benitoite . I also used the Apple clang for all tools. With a Release build, the observed latency with moving sliders, dragging curves etc is exactly the same as when compiling with OpenMP as previously described (Release). There is no perceived difference in the UI behaviour. In terms of CPU utilisation, htop shows three cores running at approx 50%, some others at zero, a couple at approx 20 when dragging a curve control up and down. Preview seems to redraw at the same speed as when compiled with OpenMP. From what I can tell, there is no real difference compiling with OpenMP or without.

The very interesting thing I found is compiling a Debug build with OpenMP disabled. UI performance is much improved! Dragging the same sliders, moving curve controls and navigating the UI in the same way as before is significantly better! Dragging scroll bars in menus is not snappy, but it is a marked improvement over a Release build.

I then tried a Debug build with OpenMP enabled and using the llvm tools for clang, clang++, ar and ranlib. Behaviour in the UI feels the same as the Debug build without OpenMP, but this time, htop shows all cores hitting 100% every so often and definitely more CPU activity / usage (as you'd expect). But strangely, the overall experience does not seem improved with Debug and OpenMP.

I'm not sure if this makes sense, but clearly a Debug build exhibits far improved responsiveness in the UI.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.