Darktable speed

I think there are two separate problems:

  1. in my experience using OpenCL for image rendering is a must (with any decent GPU), the performance difference is huge

  2. I believe that the sluggish response in lighttable is related to this issue: https://redmine.darktable.org/issues/10764 - darktable is redrawing all visible images on even the smallest mouse movements. It’s just much more noticeable on HiDPI displays, since it has to redraw more pixels. Unfortunately it seems this didn’t get much love yet, probably the impact on the user base is not that big.

  1. Yeah, I’m working on getting that working. That should hopefully at least speed up processing, and that’s where I do most of my work anyway.
  2. Yeah, I saw that bug report after you asked about my 4K display. I’m happy to help fix this issue (I didn’t realize it was an issue until I got my 4K display hahahaha).

Cool, got OpenCL support working, so at least processing now is at a decent speed. Obviously the lighttable bug is still a problem, but since I don’t really use it much except to add tags and export, it’s not a big deal.

FWIW I bought a 4k monitor last April, and there was no noticeable slowdown for me. I do run the Nvidia proprietary drivers though.

Huh, interesting. I switched to using the proprietary drivers, but still had the slowdown in lighttable (obviously using OpenCL will speed things up in actual processing). I confirmed it was the 4K resolution because switching down to 1920x1080 fixes things and everything’s back to the speed I was used to.

Weird. Maybe a difference in desktop environment? I run Slackware (KDE desktop). Maybe that has something to do with it?

Around a year ago I recall reading a post somewhere about high CPU usage in lighttable view, but I can’t find it now. Perhaps it’s the same issue you’re experiencing? Simply moving the mouse around the lighttable does use a lot of CPU on my machine (~40% of one core) but it’s not enough to cause a noticeable slowdown.

Edit: and on reading the rest of the comments here it looks like someone else has mentioned the post I couldn’t fnd! :slight_smile:

For those who are interested and have a similar problem, here is my current workaround. Since the problem is the 4K resolution, I created a script which sets the right resolution (just half in each dimension — e.g. my regular display is 3840x2160, so my “half” resolution is 1920x1080), starts darktable (along with resetting GDK_SCALE so that the interface isn’t gigantic), and cleans up by restoring the original resolution (--preferred argument to xrandr) after I exit darktable. This way, I get the awesome 4K display most of the time as well as responsive photo editing when I want it!

Of course, this workaround is most easily implemented in linux (is there even a command-line tool to set the screen resolution in Windows or macOS?). Here is the script I’m using:

#!/bin/bash

OUTPUT="eDP-1-1"
HALF_RES="1920x1080"
HALF_RES_DPI="96"
HIGH_RES_DPI="192"
DARKTABLE='firejail darktable --noiseprofiles ~/.config/darktable/noise/presets.json'

# Change resolution

xrandr --output $OUTPUT --mode $HALF_RES --dpi $HALF_RES_DPI;

# Start darktable

GDK_SCALE="" $DARKTABLE "$@";

# Change resolution back

xrandr --output $OUTPUT --preferred --dpi $HIGH_RES_DPI;

(I use firejail to sandbox programs, but that’s irrelevant — you can just as easily remove that and just start darktable "$@".)

2 Likes

Have you tested, how much firejail low down darktable?

Hi chiraag, thanks for an interesting workaroud. I may use this when working on my 15-inch laptop (which isn’t often), but my main desktop display is a 31-inch one, so unfortunately 1920x1080 would be too huge and ugly.

Weird thing though - with resolution set to 1920x1080 lighttable seems a bit snappier than on full 4K with darktable window resized to one quarter of the screen (which should result to about the same number of the redrawn pixels). Maybe something else is in play as well.

firejail does not slow down darktable at all (one of the first things I tried was running darktable without firejail - it didn’t help). I’ve never noticed a performance impact of firejail on any application (including darktable).

What is your native resolution? I use awesome window manager, so if I hide the top bar, the only indication that anything’s changed is that the wallpaper looks horrendous. But given that I reset it right back after darktable ends, as long as I don’t switch applications, I don’t think anything should be too noticeable? I think anything that’s DPI-aware shouldn’t have too many problems (although you would have to reset e.g. GDK_SCALE if you want to start a new program while darktable is running).

Huh, that is weird. I wouldn’t really know since I use a tiling window manager (so I don’t normally resize clients manually).

Driver Nouveau has poor perfs on 4K display maybe? Have you tried the proprietary Nvidia driver?

  1. I was initially running this on my on-board GPU (Intel).
  2. No other application had problems with 4K, either on nouveau or intel.
  3. I switched to running the Nvidia driver because I wanted OpenCL.
  4. Neither of those had an effect on darktable’s issue with 4K monitors. Changing the resolution did.

My native resolution is 4096x2160. I wasn’t able to set the resolution to exactly half (2048x1080), looks like my GPU card does not support it. But anyway, I tested with 1920x1080 and the pixels are just too large on the 31 inch display - the fonts look ugly etc. Also I often switch windows from darktable to a file manager etc, so unfortunately this solution is not suitable for me.

FYI I’m using Radeon RX-480 with the AMDGPU-PRO driver.

Damn, that’s a pity.

Yeah, that makes sense. For me, if I’m in darktable, I often don’t leave it until I’m done editing my photos. Here’s to hoping performance is fixed on 4K monitors in the near future :beers:

To fix it, we’d need to know exactly what is wrong, that it is actually a problem in darktable and not in another library in debian sid or a gtk issue. So best as I can see, there isn’t information this precise, but sounds like you’re narrowing it down.

Have you tried to run strace yet? What version of GTK is running in sid?

It’s https://redmine.darktable.org/issues/10764.
That is a true, valid issue. That code is … retarded, not in a good way.

1 Like

Most likely it’s tied to this (especially since changing the resolution largely fixes the problem). I can certainly upload strace logs here or to that bug report…which is preferred? The current version of GTK+ is 3.22.26 in sid, but I’m pretty sure (looking at the changelog) that there hasn’t been an update to libgtk-3-0 since November (and my old laptop died towards the end of January).

I’d love to help resolve this issue in any way I can :slight_smile: What needs to happen for progress to be made on this? Will this require refactoring a large portion or is this a fairly self-contained issue?

I stand corrected, sorry @chiraag! Thanks @LebedevRI