Darktable becomes non-responsive when maximized to full screen
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.
#2 Updated by Robert Chapman over 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 over 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