macOS: lighttable scrolling nearly unusable and preview very slow since 3.2.1

[apfelkraut]

Environment

• macOS 10.15.6
• Macbook Pro 16, i9-9880H, 16GB, SSD
• openCL devices: 'Intel(R) UHD Graphics 630' (device 0), 'AMD Radeon Pro 5500M Compute Engine' (device 1)
• Darktable 3.2.1 / 3.0.2 directly downloaded as .DMG from Darktable's official GitHub releases
• about 800 RAW images (.NEF) of a Nikon D750

Steps to reproduce

1. Remove any previous /Applications/darktable.app
2. Clean config/cache (delete ~/.config/darktable and ~/.cache/darktable)
3. Do a fresh install of 3.2.1 / 3.0.2 without changing any configuration. Note: Due to default setting, OpenCL is not activated
4. Import images
5. Scroll through images e.g. in a 5 images per row grid (by using trackpad or mouse wheel)
6. Open a preview (selecting one image and pressing "w")

Current behaviour (as in 3.2.1)

• images get imported without showing any thumbnails during import process
• thumbnails start popping up (being displayed one after the other) only after import has finished
• scrolling is not smooth and in an uncontrolled manner (a swipe brings you somewhere much further within the collection; 2-3 swipes can bring you at the end of the collection; two down and two up will not bring you to the same images/row)
• during scrolling thumbnails are popping in, nearly one after the other as if they are being loaded from a very slow disk
• preview takes 2-3 seconds to display

Expected behaviour (as in 3.0.2)

• images get imported whilst thumbnails are shown instantly as they are being added without any delay
• scrolling through thumbnails is smooth and in a controlled manner (a swipe brings you to the next images; you can do two swipes down and then two up again to get to the same images/row)
• during scrolling thumbnails are displayed instantly, no delay
• preview is shown instantly without any delay

Further notes

• activating OpenCL => "multiple GPUs" did not bring any significant improvements if any at all
• tried e.g. opencl_device_priority=!Intel(R) UHD Graphics 630,/!AMD Radeon Pro 5500M Compute Engine,/AMD Radeon Pro 5500M Compute Engine,/AMD Radeon Pro 5500M Compute Engine,
• no difference when scrolling with mouse or trackpad
• changing theme does not have any effect on the described behaviour
• same workflow on a rather old, slow Linux machine is blazing fast with 3.2.1

Workaround

• scroll with cursor keys
• accept slowness and have coffee
• get a Linux machine

[MStraeten]

multiple GPUs doesn’t help on osx macbook pro 16 since then the cpu graphic is prioritized over the GPU.
I found tweaking opencl settings in ~/.config/darktable/darktablerc improves a lot. Here my setting for gpu priority:
opencl_device_priority=1,0,*/0,1,*/1,0,*/0,*/*
and opencl_scheduling_profile=default
in my configuration 1 is the AMD Pro 5500M an 0 the CPU graphic.
So the GPU is prioritized for processing the full pixel pipe and export and the cpu graphics for preview and thumbnail processing.
It’s worth to read https://darktable.gitlab.io/doc/en/darktable_and_opencl.html for further tweaking

for the swipe issue - it’s fine with an old fashioned mouse wheel but darktable and trackpad or magic mouse aren’t best friends - darktable is quite sensitive ...

[apfelkraut]

@MStraeten thanks a lot for your feedback.

You got me, I was indeed using also a magic mouse for scrolling. Replacing it by a Logitech bluetooth mouse brought back scrolling via mouse wheel in a controlled way. I am still wondering, why it worked very well with mac's touchpad and magic mouse in 3.0.2 and stopped to do so in 3.2.1?

I also tried your advice on enabling OpenCL with the suggested setting. Well, hard to say ... it might be slightly faster, but I still get the observed behaviour as described above. Again ... strange that it worked with 3.0.2 (even without OpenCL) and now is perceived much slower in 3.2.1 although the release notes suggest something different: "...lighttable view has been rewritten... resulting in large performance gains ..." .

Site note: I am well aware of that Darktable is developed and optimized for Linux and we as Mac user's can consider us very lucky to also get a share of this beautiful application. But well, would be so great to also profit from these performance gains or at least preserve the speed of 3.0.2 in 3.2.X on macOS.

I am really no expert but of course have some guess ... maybe for the performance optimization some GTK functions have been used that are not available or not effective on macOS or some compatibility options have been abandoned in favour of the performance gains? (which is all fine but would be interesting to understand)

[Firstyear]

@apfelkraut I can reproduce this behaviour on a mbp with i7 + 32GB of ram + Radeon 555x. The latest updates have made darktable sadly very hard to use :(

Is there anything I can provide to assist? Video of the issue or trace logs? I have already tried adding the suggested opencl settings.

[AlicVB]

lot of different things in this issue... I have no access to any Mac, so I can just guess and ask...

1. scrolling and mouse : There has been some report from @Nilvus iirc, but they should have been fixed in june, so before 3.2.1 Maybe Mac is doing some special things with scrolling events... Can you confirm that the problem wasn't present in 3.0.x ?
2. the slowness : is it still slow if you browse again through images that have already been load without a darkatble restart ? same question after a darktable restart ?
3. thumb loading : this as been done on purpose to gain some substantial speedup in importation. But I agree that we can enhance this part in term of user information !

now about the optimizations : in fact we now use "regular" gtk widgets instead of doing all the drawing ourselves, so imo that should increase compatibility, but things are not so bright apparently...

thanks for your answers

[apfelkraut]

Thanks a lot @AlicVB for your interest, the questions, and the background!

1. scrolling and mouse : confirmation that 3.0.2 .dmg from Github releases works very well (on same machine, same macOS, same devices, that's currently my fallback)

2. the slowness (observations after clean install) :

   1. thumbnails : once loaded they are there. browsing through thumbs works as expected (fast), thumbs appear with minor to no delay. a restart does not change this behaviour, browsing through thumbs remains as expected (fast).
   2. preview : slow (2-3 seconds) for making first preview of an image, repeated preview of same image is fast (<1 seconds), previewing next images and then going back to first for repeated preview is again slow (2-3 seconds). same after restart, slow preview (2-3 seconds).

3. thumb loading : sorry not be clear about this one. No worries, I personally do not see this as a problem, just wanted to mention it because it was also different to 3.0.2 ...

[Firstyear]

I can confirm all the same information as @apfelkraut, with some additional information to point 2.

In rendering previews the preview is slow to render as mentioned (2-3 seconds) per image. When it does load it appears to load a small copy offset in the corner, then a full size glitched in an incorrect location, and then finally it loads in the correct location/scale. So it creates a very choppy effect on the screen. After an image has been previewed once it's "faster" to load, but still not "instant" as I have observed in past versions. It seems like darktable isn't "looking ahead" to render future images in the series.

Restarting darktable causes the rendering to reset as mentioned, which probably indicates that the in memory cache isn't being flushed to disk during runtime or at shutdown. I've noticed this problem in the past and I believe the work around was after a large import to run /Applications/darktable.app/Contents/MacOS/darktable-generate-cache so that you cause the on-disk mip maps to be created, and to lower the size of the thumbnail cache memory to force cache evictions to disk sooner.

[AlicVB]

For the slowness, you can see where the thumbnail is grab from by launching dt with -d cache you will see line like [mipmap_cache] grab mip 1 for image 410 from disk cache (you see no lines if the thumbnail is retrieved from memory)

When it does load it appears to load a small copy offset in the corner, then a full size glitched in an incorrect location, and then finally it loads in the correct location/scale. So it creates a very choppy effect on the screen

yes, this is a know glitch which is almost fixed in current master

Restarting darktable causes the rendering to reset as mentioned, which probably indicates that the in memory cache isn't being flushed to disk during runtime or at shutdown

Can you verify that point with -d cache ? If effectively the thumbnail is regenerated from scratch each restart, there's a bug somewhere...

[Firstyear]

For the slowness, you can see where the thumbnail is grab from by launching dt with -d cache you will see line like [mipmap_cache] grab mip 1 for image 410 from disk cache (you see no lines if the thumbnail is retrieved from memory)

When it does load it appears to load a small copy offset in the corner, then a full size glitched in an incorrect location, and then finally it loads in the correct location/scale. So it creates a very choppy effect on the screen

yes, this is a know glitch which is almost fixed in current master

Ahh great, thanks!

Restarting darktable causes the rendering to reset as mentioned, which probably indicates that the in memory cache isn't being flushed to disk during runtime or at shutdown

Can you verify that point with -d cache ? If effectively the thumbnail is regenerated from scratch each restart, there's a bug somewhere...

Now that I'm trying to produce it I can't. I wonder if it was because I was at different zoom levels in the image viewer? That would certainly cause different mip maps to be generated all the time ...

Trying out some stuff related to opencl, I can see that if I have the MBP on external displays to force the radeon, image preview generation is much faster, so I wonder if the darktable on macos needs to indicate that it wants to use the discrete GPU? When on the integrated card I can see the 3 second-ish image generation, but on discrete it's much faster, about 1 second with opencl. IIRC this a flag you can set in the plist.

https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching
https://developer.apple.com/documentation/bundleresources/information_property_list/gpuselectionpolicy

Also I'm finding that the default cache generate tool mip level is too low. For @apfelkraut if you have a large batch to import, you could find the following helpful:

/Applications/darktable.app/Contents/MacOS/darktable-generate-cache --max-mip 4 --min-imgid XXXX

I find that the "large" previews tend to be mip level 3 or 4, and smaller thumnails are 0 or 1, so this should generate every thing you need at various display levels. Be aware that editing an image of course invalidates the pre generated content though.

[apfelkraut]

Wow ... thanks @Firstyear and @AlicVB. These are quite some hints!

I did not have time to try the plist tweaking as described in the links. @Firstyear Do you have a working plist config to activate the discrete GPU even if you are not connected to an external monitor?

@AlicVB regarding the caching question: In short - it seems that caching works as expected though the preview is still much slower in 3.2.1 compared to 3.0.2 . Note that compared to my previous report this was executed on a MacbookPro 13 (just as hint regarding the mimaps size). In addition the default darktable configuration was changed to also cache full previews.

Steps to reproduce

1. Install fresh (delete any previous config and cache) darktable 3.0.2
2. Configure darktable to
   • not use OpenCL (default)
   • enable disk backend for thumbnail cache (default)
   • enable disk backend for full preview cache
3. Import e.g. 20 NEFs
4. Scroll/browse through images
5. Open preview (pressing key "w")
6. Close and restart darktable
7. Scroll/brows through images
8. Open preview (pressing key "w")
9. Upgrade to darktable 3.2.1
10. Delete $HOME/.cache/darktable
11. Scroll/brows through images
12. Open preview (pressing key "w")
13. Close and restart darktable
14. Scroll/brows through images

3.0.2 behaviour

• mimaps of size 1, 2, and 6 are generated
• display of thumbnails and preview is fast as expected

3.2.1 behaviour

• mimaps of size 3, 6, and 8 are generated
• according to -d cache they are first generated and then - even after restart - as expected read from cache and not re-generated
• display of thumbnails while browsing is quite fast as soon as they are cached
• preview is initially slow (2-3 seconds)
• after being cached, repeated preview of same image is fast as expected
• after previewing several different images and going back to the first one, as well as after a restart, the preview is again slightly faster, but still slow (1-2 seconds) although it is grabbed from cache => This is strange as in 3.0.2 it immediately appeared, and well from a pure UX perspective not so nice when you quickly want to sneak into an image at full size

By the way, probably not related, but when I start darktable from command line I see the following GTK related messages:

(process:6772): GLib-GObject-CRITICAL **: 21:24:26.578: g_object_set: assertion 'G_IS_OBJECT (object)' failed
(darktable:6772): GLib-GObject-WARNING **: 21:24:27.345: invalid cast from 'GtkMenuBar' to 'GtkWindow'
(darktable:6772): Gtk-CRITICAL **: 21:24:27.345: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed

[Firstyear]

Wow ... thanks @Firstyear and @AlicVB. These are quite some hints!

I did not have time to try the plist tweaking as described in the links. @Firstyear Do you have a working plist config to activate the discrete GPU even if you are not connected to an external monitor?

It took me a while but I realise that with the nssupportgpuswitch you also need an opengl context:

https://developer.apple.com/library/archive/qa/qa1734/_index.html

So this plist change doesn't have the effect you may want.

• after previewing several different images and going back to the first one, as well as after a restart, the preview is again slightly faster, but still slow (1-2 seconds) although it is grabbed from cache => This is strange as in 3.0.2 it immediately appeared, and well from a pure UX perspective not so nice when you quickly want to sneak into an image at full size

In activity monitor you can check your disk IO rates to see if that's a bottleneck here?

By the way, probably not related, but when I start darktable from command line I see the following GTK related messages:

(process:6772): GLib-GObject-CRITICAL **: 21:24:26.578: g_object_set: assertion 'G_IS_OBJECT (object)' failed
(darktable:6772): GLib-GObject-WARNING **: 21:24:27.345: invalid cast from 'GtkMenuBar' to 'GtkWindow'
(darktable:6772): Gtk-CRITICAL **: 21:24:27.345: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed

[Firstyear]

For now you could uncheck 'sysprefs > energy saver > automatic gpu switch' if you need the faster opencl devices.

[sblock23]

Hi All,
Just as a second on the mouse issue. I have tested this on 2 Macs:
Core i9 2019 iMac (40GB RAM) 27" 500GB SSD
2019 16" Macbook Pro 16GB RAM 500GB SSD

Both are running 10.15.6.
The mouse scroll is uncontrollably fast on the:

• Magic mouse 2 (both)
• Trackpad (MacBook)
• Wireless trackpad (iMac)

However if I use a good ol' USB mouse that I have lying around for when my mouse batteries go flat right when I'm about to bid on an eBay auction (circa 1998) then the scrolling works fine!

I have not tested earlier version of darktable as I just discovered it a few weeks ago and am looking for a replacement for Lightroom when my licensed copy stops working. So I can't comment on how this differs to the earlier version or the comparative speed of thumbnails, etc.

There is definitely an issue with the Apple pointing devices, most likely a driver incompatibility. I hope this gets fixed in the next version as it really makes it unusable and the old mouse is way to clunky.

Cheers.

[github-actions]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[d4rkd3v1l]

I really like darktable, and have been using it for years now.

Ok actually I found the performance always kinda borderline, but it was "good enough" and therefore working out for me.
But now, especially the lighttable is completely unusable, image load like forever, and scrolling is so unsmooth...

I'm using darktable on a 2018 MacBook Pro 13" (i5 2.3, 16GB RAM) together with a Radeon Vega 64 eGPU on a 4K display.
For sure that's not the best you can get as of 2020, but should be enough to have an app like darktable running smoothly, I guess.

Already tried some stuff from this post here, but didn't feel any improvement whatsoever. :-(

[jackdyson31]

Turning off trackpad scroll with inertia in System Preferences>Accessibility>Mouse & Trackpad>Trackpad Options improves the situation in LightTable. The Mac trackpad driver seems to be set to very high gain as far as DarkTable is concerned, mainly because it scrolls one "page" of images per swipe as opposed to smooth scroll ...there is also the option of turning on the scroll bar to help. Everything else seems to work ok on my Mid 2012 Macbook Pro.

[sblock23]

Turning off trackpad scroll with inertia in System Preferences>Accessibility>Mouse & Trackpad>Trackpad Options improves the situation in LightTable. The Mac trackpad driver seems to be set to very high gain as far as DarkTable is concerned, mainly because it scrolls one "page" of images per swipe as opposed to smooth scroll ...there is also the option of turning on the scroll bar to help. Everything else seems to work ok on my Mid 2012 Macbook Pro.

i tried turning off inertia for the mouse options, lowering the speed and disabling the spring loaded delay. Still quite unusable. I'm hopeful this is addressed in the next version of DT as it clearly behaves quite different to any other app on the Mac in this regard.

[jackdyson31]

@sblock23 : sorry to hear that; here I use the track-pad on my macbookpro and turning off the inertia made light-table scroll "in pages" like a bad browser window, not great admittedly, but I thought it was an improvement and it shows what needs changing codewise - I think using the scroll bar which works ok is however better - having noted all of that, I do agree something needs to be done ... I'm going to look for a (safer) older version in the meanwhile.

It is ironic as I use RawTherapee on the mac (which runs very well), and I thought I'd give darktable a try when I find that the manual is completely different and then this happens to boot ... fingers crossed then.

EDIT: can confirm that 3.0.2 is running well on my Macbook Pro, mid 2012, i7, 16 Gb, NVIDIA 650M 512 Mb, 1 Tb Samsung SSD and conforms to the manual.

[parafin]

Scrolling behaviour change is most likely related to lighttable rewrite by @AlicVB. I think smooth scroll events (different from ordinary scrolls) are handled somehow wrongly. Though another possibility is that GTK is to blame and this issue was introduced in some recent version.

[AlicVB]

yes, it's certainly a problem on my rewrite. Sadly, I have absolutely not clue of what happen, and I don't have a Mac to test... So it's quite difficult to figure how to solve that :(

[jackdyson31]

@AlicVB I am extremely grateful that we can have great great software like this for free mate, you did a fantastic job - so like, no worries and a big thank you. I'll try and see if I can recompile it myself at some point (IF I can understand how ;D).

@parafin I agree - its the smooth scrolling being mangled by GTK on the Mac implementation. To be clear I don't think the GTK "smooth scrolling" works particularly well (without opencl) even when correctly running, I have RawTherapee running beside Darktable and like it scrolls its file manager quite a bit faster (out of the box) ... might be an idea to recompile the new code with an older GTK version and see what happens? e.g. the same version that is used on the 3.0.2 release if that be different ?

[lhietal]

I tested lighttable scrolling with the trackpad on my Macbook.

GDK_SCROLL_SMOOTH deltas are around the range -500 to 500 on my system. I'm not exactly sure what it is. It seems that the numbers are in relation to display dimensions.

This leads to dt_gui_get_scroll_unit_deltas() in gtk.c not handeling that properly and _event_scroll() in thumbtable.c moves thumbnails every time scroll event is updated.

There is a similar issue in Beep6581/RawTherapee#5599.

• macOS 10.14.6
• Darktable 3.5.0 (545b7e8)
• gtk 3.24.24

---

The UX with a trackpad could possibly be improved by not forcing thumbnails to align at the top edge. I think having closer interaction between the finger movement and scrolling bahaviour gives better spatial awarenes. Otherwise when there are only few rows of thumbnails visible scrolling leads to thumbtable changing completely.

I used following changes to test the interaction.

diff --git a/src/dtgtk/thumbtable.c b/src/dtgtk/thumbtable.c
index e2e49c93f..6a5aea3af 100644
--- a/src/dtgtk/thumbtable.c
+++ b/src/dtgtk/thumbtable.c
@@ -877,7 +879,7 @@ static gboolean _event_scroll(GtkWidget *widget, GdkEvent *event, gpointer user_
   dt_thumbtable_t *table = (dt_thumbtable_t *)user_data;
   int delta;
 
-  if(dt_gui_get_scroll_unit_delta(e, &delta))
+  if(dt_gui_get_scroll_unit_deltas(e, NULL, &delta))
   {
     if(table->mode == DT_THUMBTABLE_MODE_FILEMANAGER && (e->state & GDK_CONTROL_MASK) == GDK_CONTROL_MASK)
     {
@@ -892,13 +894,14 @@ static gboolean _event_scroll(GtkWidget *widget, GdkEvent *event, gpointer user_
     }
     else if(table->mode == DT_THUMBTABLE_MODE_FILEMANAGER || table->mode == DT_THUMBTABLE_MODE_FILMSTRIP)
     {
       // for filemanger and filmstrip, scrolled = move
       if(delta < 0 && table->mode == DT_THUMBTABLE_MODE_FILEMANAGER)
-        _move(table, 0, table->thumb_size, TRUE);
+        _move(table, 0, trunc(-delta), TRUE);
       else if(delta < 0 && table->mode == DT_THUMBTABLE_MODE_FILMSTRIP)
         _move(table, table->thumb_size, 0, TRUE);
       if(delta >= 0 && table->mode == DT_THUMBTABLE_MODE_FILEMANAGER)
-        _move(table, 0, -table->thumb_size, TRUE);
+        _move(table, 0, trunc(-delta), TRUE);
       else if(delta >= 0 && table->mode == DT_THUMBTABLE_MODE_FILMSTRIP)
         _move(table, -table->thumb_size, 0, TRUE);

[jackdyson31]

@Ihietal Hello there ! Season's greetings and thank you for updating the issue. What was the result of your test ? Does it make it run better ?

[lhietal]

I have very little coding experience so I would appreciate any opinions from @parafin. Scaling the input from event->delta_x and event->delta_y seems to produce nicer scrolling. I'm assuming that all GDK_SCROLL_SMOOTH events are similar on macOS.

This change also affects other plases in the UI. For example resizing tagging and image info modules is much slower.

diff --git a/src/gui/gtk.c b/src/gui/gtk.c
index e03388b9c..caad824b9 100644
--- a/src/gui/gtk.c
+++ b/src/gui/gtk.c
@@ -654,8 +654,13 @@ gboolean dt_gui_get_scroll_unit_deltas(const GdkEventScroll *event, int *delta_x
       // accumulate trackpad/touch scrolls until they make a unit
       // scroll, and only then tell caller that there is a scroll to
       // handle
-      acc_x += event->delta_x;
-      acc_y += event->delta_y;
+      #ifdef GDK_WINDOWING_QUARTZ
+        acc_x += (2.0 / 400.0) * (event->delta_x + 200) - 1;
+        acc_y += (2.0 / 400.0) * (event->delta_y + 200) - 1;
+      #else
+        acc_x += event->delta_x;
+        acc_y += event->delta_y;
+      #endif
       const gdouble amt_x = trunc(acc_x);
       const gdouble amt_y = trunc(acc_y);
       if(amt_x != 0 || amt_y != 0)

[twenster]

HI,

I tried DT 3.4.0 on my iMac late 2015 (27 Inch), 3,2 GHz Intel Core i5 four cores, 16GB RAM, AMD Radeon R9 M390 2 GB with OpenCL on, with macOS 11.1 Big Sur.

The scrolling issue using a magic mouse and Magic trackpad still happens on the main view (photo thumbnails). A swipe up down, left or right scroll "per page" or multiple page at once.

However, swiping up / down on the left and right columns are smooth, scrolling in lists (keyword list for example) is also smooth.

The problem only seems to be in the thumbnails view.

EDIT:

• On a side note, the bottom slide which select how many thumbnails are display per row, is also very sensitive. One swipe up, down, left or right can display 1 or 25 thumbnails. No need to click.
• Wondering how a Microsoft Surface mouse, Microsoft Arc Mouse react. hey have not scroll wheel neither, and you can swipe in every directions.

[jonastr]

I am really starting to like Darktable for all the other things it can do, but proper scroll behavior isn't one of them. It's really driving me nuts. :( I understand that possibly MacOS is not the main focus of this project, but then I'd assume any workaround such as #7904 is better than the current broken behavior, no?

So, what's the plan on fixing this issue / getting the PR integrated?

[parafin]

#7904 partially fixed this issue.

[jonastr]

Thank you all so much for the contributions on this one! Just updated to 3.4.1 and it made trackpads+wheel-less mouses usable again. Sweet!

I would agree with @lhietal though that continuous scrolling would even be better for trackpad use (instead of scrolling row by row).

Still, thanks much!

[apfelkraut]

If there are no objections, I would close this issue. Thanks a lot to everyone who contributed to resolving it!!

• With 3.4.1 scrolling is smooth again when using the built-in trackpad (I currently do not have a magic mouse at hand, but with mouses of other vendors it never was an issue).
• With 3.4.1 loading of previews is close to instant. Perceived delay/slowness is gone.

Verified on the same hardware that brought me to reporting this issue ... meanwhile running macOS 11.

(Note to myself: Next time, open one issue per problem ;-))

[CDSRV]

The grid/lightbox view is impossibly slow on Linux (fc37.x86_64) with latest version 4.2 - using keyboard navigation -- unrelated to any mouse config & will not utilize available RAM when set to unrestricted.

[MStraeten]

it doesn’t help to file that Linux issue in that osx thread. The issue described here was a very macOS specific issue.
If your want to get support, please file a new issue providing the requested information