I’m using 5.2.0 on Windows 11.
Switching from lighttable module to darkroom module takes about 18 seconds on my machine. Switching back takes approx. 5 seconds. That is also the time to switch from lighttable module to maps module. From maps module to darkroom module it takes also about 18 seconds.
Is there a reason for the huge difference in the duration of module switching? Is darkroom module so much “heavier” than the other modules?
you might check if opencl is activated.
head over to C:\Users\<username>\AppData\Local\darktable and serach in darktablerc file for a line like this: "cldevice_v5_...=0 250 0 16 16 128 0 0 0,000 0,000 0,250
if the eigth parameter isn’t 0 then switch it to 0 and change the opencl entry to opencl=TRUE to enable opencl support.
That might improve processing, but if you have just an integrated GPU or limited memory then this even can slow down further.
Just try it and if it slows down the system, you can switch off opencl in the preferences dialog.
Post the file with the output from darktable -d common.
Are your raw files in a network path?
Opencl is activated and used as expected. If I do not activate OpenCl the program is not usable.
PS C:\Program Files\darktable\bin> ./darktable.exe -d common
PS C:\Program Files\darktable\bin>
PS C:\Program Files\darktable\bin> .\darktable-cltest.exe
darktable 5.2.0
Copyright (C) 2012-2025 Johannes Hanika and other contributors.Compile options:
Bit depth → 64 bit
Debug → DISABLED
SSE2 optimizations → ENABLED
OpenMP → ENABLED
OpenCL → ENABLED
Lua → ENABLED - API version 9.5.0
Colord → DISABLED
gPhoto2 → ENABLED
OSMGpsMap → ENABLED - map view is available
GMIC → ENABLED - Compressed LUTs are supported
GraphicsMagick → ENABLED
ImageMagick → DISABLED
libavif → ENABLED
libheif → ENABLED
libjxl → ENABLED
LibRaw → ENABLED - Version 0.22.0-Devel202502
OpenJPEG → ENABLED
OpenEXR → ENABLED
WebP → ENABLED
As you can see, no debug on Windows. And yes I downloaded from https://www.darktable.org/install/.
All my Pictures are on M2.SSD attached to PCI4.0 bus.
Opening the next image in Darkroom takes 1s.
System is a Laptop with 32GB RAM, Ryzen 9 6900HX with AMD Radeon 6600MX. The onboard GPU is deactivated. All drivers are up to date.
So I am asking, because everything works in a fast enough way. Only switching to darkroom takes ages.
Not on Windows so not sure of the details, but I know logs get written to a folder in Documents.
Do you mean the folder:
C:\Users\xxx\AppData\Local\darktable\
Nope, only db’s , snapshots of db’s, some rc’s, and 2 folders without a log inside.
If i remember correctly, there once were files inside a hidden InternetExplorer folder, but that was fixed sometime in the 4.x era. I checked and it was C:\Users\xxxx\AppData\Local\Microsoft\Windows\INetCache\darktable and behold! a logfile. From 4.8.1 
. SO it seems that 5.0 fixed this. But where is the logfile now?
In the early 4.x era the switch between lightable and darkroom was way snappier, but since about 1 1/2 years ago it started to get slower. And today was the day I finally decided to ask the question: Why?
This was clearly a question not fitting for Reddit and a bit to early to raise as issue in github. Also without the debug option raising a bug is a bit complicated. So I thought, maybe someone using darktable on Windows 11 answers with “Me too!” or a developer with “Thats because the number of modules that need to be loaded in darkroom is about 5 times bigger then in other modules. And also Windows does not work nice with regard to custom GUI elements.”
Hi, have you already looked in the folder C:\Users\<userName>\Documents\Darktable? The location has changed with 5.2 as far as I remember. So logs should go there 
darktable-log.txt (87.8 KB)
Hoisted by my own petard. I switched the Documents location to my D: for reasons. So when I open Documents Windows does not show me the contents of C:\Users\xxxx\Documents, but the contents of D:\Documents. So I had to navigate to C:\Users\wensk\Documents\ by CLI and there I found the Darktable folder. It was the only folder or file in it.
Above darktable.log contains 2 runs, first with
darktable -d perf
second one with
darktable -d common -d perf
In both runs I tried to perform the same actions:
Wait until darktable has started and wait for lighttable to be shown
Click on top right thumbnail to select
Click on darkroom module
After darkroom module has loaded with raw visible switch back to lighttable
Exit programm
In both runs there is a span of time without logentry. In the first from 38,1652 to 63,6991 , in the second from 44,3221 to 60,3958.
This seems to be when the switch happens.
Thanks for the hint with the documents folder. My bad not finding it the first time.
Post the -d all. The -d common doesn’t explain the issue.
Fyi, opencl is working
I’m on a cellphone, so reading the file is really hard. I don’t see anything quickly to point to the source of the problem.
Things to try: as a test, start dt with a blank new config, disable lua scripts. If no improvement, start a GitHub issue.
Renamed the AppData/Local/darktable folder
Started darktable with -d all
imported a folder with a few raws
ensured OpenCL was activated
switched between lighttable and darkroom multiple times
quit darktable
The log again contained timespans without log entries as before, so it is not a config issue.
I suspect OpenCl on older AMD mobile GPUs has some performance issue, especially on Windows. This seems to be the root cause
Since my gear is not a very common one and nobody else iseems to have a similiar problems I will not raise a github issue. It’s just not worth it. The dev’s time is better used to give us cool features than chasing obscure issues. I can work with darktable and have adapted my workflow to only switch between modules if really necessary.
The new machine I will buy for Christmas will be a desktop with NVIDIA GPU, since AI models also are not working/are a hassle on my current machine.
The time gap was not around the opencl operations.
I did not say opencl causes the issue, it may be responsible, it may be the AMD driver, it may be the UI-Elements handling or even some arcana deep in the belly of Windows. Without running a debugging session we will not know for sure.
What I know is that around the time I switched the modules, there is a gap in the log entries and the surrounding logs seem to support this pov.
Let me try to explain my reasoning:
33,6406 [dev_process_thumbnail] pixel pipeline processing took 0,193 secs (0,219 CPU)
38,1652 [dt_dev_load_raw] loading the image. took 0,117 secs (0,125 CPU)
63,6991 [histogram] took 0,000 secs (0,000 CPU) scope draw
33.6 lighttable module/view is finished loading thumbnail for middle pane
shortly before 38.1 I click on darkroom to initiate the switch
38.1 darkroom loads the raw to develop, darkroom is not yet visible
Whatever causes the long wait happens without logs, maybe this is not even caused by darktable code.
63.6 darkroom module/view starts to draw the histogram and darkroom is visible
The span between between both timestamps corresponds with the duration I handstopped for the duration of the module/view switch. This may only be a correlation, but my more than 30 years of QA work in the business have taught me one thing:
When there is smoke, there is a smoldering fire and I may dig a little bit deeper.
And my bet is on opencl/Rocm for older AMD GPUs.
You could try disabling OpenCL and loading a low-res JPG or a low-res raw from an old camera, just to check if the issue has anything to do with OpenCL and processing, or if darktable hangs somewhere, not performing any processing at all.
darktable-log.txt (654.2 KB)
darktable -d all
Deactivated Opencl and restarted darktable to ensure that the setting was used.
Imported this jpg and opened it in darkroom
40,8662 [sql] C:/msys64/home/bill/src/darktable-5.2.0/src/common/tags.c:769, function dt_tag_get_attached(): prepare “SELECT DISTINCT I.tagid, T.name, T.flags, T.synonyms, COUNT(DISTINCT I.imgid) AS inb FROM main.tagged_images AS I JOIN data.tags AS T ON T.id = I.tagid WHERE I.imgid IN (9834) AND T.id NOT IN memory.darktable_tags GROUP BY I.tagid ORDER by T.name”
55,5568 [dt_get_system_gui_ppd] system ppd is 2,000000
55,5569 [screen resolution] setting the screen resolution to 96,000000 dpi
And there was a gap about the time I clicked on darkroom, so opencl does not seem to be the culprit as it happens even when it’s disabled. So it’s fine I did not bet any money.
I also noticed while doing the test, that after the click to start the switch no tooltips were shown while hovering over UI elements. After darkroom has been shown the tooltips started to appear again when hovering over UI elements.
