Bug #9891

Darktable becomes non-responsive when maximized to full screen

Added by Robert Chapman about 5 years ago. Updated almost 5 years ago.

Target version:
Start date:
Due date:
% Done:


Affected Version:
hardware architecture:


when maximizing darktable, I noticed that many functions stopped working, for example, I select an image and in the selected image(s) menu I click remove... and nothing happens. If I scale the screen to about 1035x1100 it starts working as expected. My screen size is 1920x1200.. I did some debugging and found that when I re-size the screen to just over 1035x1100 execution of the code goes into a loop and starts becoming unstable. I'm Running darktable-1.4.1-3.fc20.x86_64 on Fedora 20 - Kernel 3.13.7-200.fc20.x86_64 - PNY GTX770 4G @ 1920x1200 - kmod-nvidia-304xx-3.13.7-200.fc20.x86_64-304.119-2.fc20.9.x86_64.

If I resize darktable to below 1035x1100 everything works as expected.

Related issues

Related to darktable - Bug #9965: lighttable stuck in regenerating preview Closed: invalid 05/20/2014


#1 Updated by Pascal de Bruijn about 5 years ago

Are you using OpenCL by any chance?

Does this still happen when you start darktable with the --disable-opencl parameter from a Terminal?

#2 Updated by Robert Chapman about 5 years ago

Yes, I'm using OpenCL, and it does still happen with OpenCL disabled. When I'm debugging with -d all I noticed a message "[add_job] 30 load image 3027 mip 1
[add_job] too many jobs in queue!" I don't think this is related to the root cause, but more of a symptom. When I first start DT it seems to behave, but soon as I do or interact with the interface it seems to go off into the loop. As soon as I resize DT to something smaller than 1035x1100 it stops and starts working as expected. Resize or Maximize it starts misbehaving once again. I'm going to see if I can figure out what source file the loop is occurring. I'll post what I find as soon as I get the information.

#3 Updated by Philipp Christ almost 5 years ago

Just thought I add this here after it looks like I experienced the same behaviour today.

I can see DT refreshing the lighttable in the console/log and after reading this redmine issue I also noticed that I couldn't use functions like remove while this was happening.

It only seems to happen if the lighttable "viewport" reaches a certain width depending on the number of images per row.

On my system it happens when the following conditions are met:
a) images_in_row >=2
b) Lighttable viewport has to be greater than (images_in_row * 716px) (eg. 716.3333) for some reason
c) The collection has to have images in the view below the currently visible ones.

The last one seems to be related to the prefetching of images(?). But I couldn't figure out where these conditions came together in a way that caused the expose signal to be emitted continuously.
The stack seems to behave and memory does not go up as far as i can tell.

A similar behaviour is showing up in zoomable mode.

Since the 716px seem likely to be different on Robert's system they must either be irrellevant or depending on another variable i couldn't make out.

As opposed to the initial report it also happens here when DT starts given the above conditions are met.

Version is 1.5+932~gf6129f8 (fetched today) on a 14.04 kubuntu

#4 Updated by Roman Lebedev almost 5 years ago

  • Related to Bug #9965: lighttable stuck in regenerating preview added

Also available in: Atom PDF