Bug #10765

High CPU and GPU usage when hovering over Darkroom thumbnail

Added by John Morris about 4 years ago. Updated over 3 years ago.

Start date:
Due date:
% Done:


Estimated time:
Affected Version:
hardware architecture:


In Darkroom mode, the mouse pointer hovering over a tumbnail causes markedly increased GPU and CPU usage.

Screenshot from 2015-12-09 11_04_46.png (139 KB) Screenshot from 2015-12-09 11_04_46.png NVIDIA X Server GPU status John Morris, 12/09/2015 02:46 AM
Screenshot from 2015-12-09 11_49_50.png (67 KB) Screenshot from 2015-12-09 11_49_50.png System Monitor John Morris, 12/09/2015 02:50 AM

Associated revisions

Revision 48472f2a (diff)
Added by Tobias Ellinghaus about 4 years ago

Fix a loop in draw/mouse_over_id handling

This fixes #10765. It will most likely introduce cases where users' Lua
code isn't updating the gui when it changed something. Those cases have
to be fixed case by case when we find them.


#1 Updated by Pedro Côrte-Real about 4 years ago

  • % Done changed from 0 to 10
  • Status changed from New to Confirmed

While in the lighttable only moving between images causes a higher cpu load in the darkroom film strip that load is continuous even when the mouse isn't moving.

#2 Updated by Tobias Ellinghaus about 4 years ago

At least on lighttable that seems to be the OpenMP loop converting thumbnail data for display (d6b9c5ae9ae1a0129128921d9aa320dfe80350dc).

#3 Updated by Tobias Ellinghaus about 4 years ago

  • System changed from Ubuntu to all
  • % Done changed from 10 to 50
  • Target version set to Candidate for next major release
  • Assignee set to Tobias Ellinghaus
  • Status changed from Confirmed to In Progress

Confirmed for filmstrip, too, there it's a proper bug.

#4 Updated by Tobias Ellinghaus about 4 years ago

So, I worked out what happens, posting here for reference:

  • the mouse is moved over the filmstrip
  • filmstrip redraws itself
  • in the draw callback it sets the mouse_over_id
  • that triggers a DT_SIGNAL_MOUSE_OVER_IMAGE_CHANGE signal
  • metadata_view connects to that signal and updates its information
  • it calls dt_lua_do_chunk_async()
  • that eventually calls dt_lua_redraw_screen()
  • which in turn makes gtk redraw all widgets
  • goto 2

Besides metadata_view there is also lua/gui.c which does the same.

#5 Updated by Tobias Ellinghaus about 4 years ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Fixed

#6 Updated by John Morris about 4 years ago

Good, works fine, thanks.

#7 Updated by Salamandar Salamandar over 3 years ago

I'd like to report that this bug is either not fixed or came back.
I'm using Darktable 2.1.0+2082~g7cbc9ec on ArchLinux.

Also available in: Atom PDF

Go to top