Project

General

Profile

Bug #10764

Slow hover response over Lighttable Thumbnails

Added by John Morris over 2 years ago. Updated 2 months ago.

Status:
Incomplete
Priority:
Low
Assignee:
-
Category:
Lighttable
Target version:
-
Start date:
12/09/2015
Due date:
% Done:

20%

Affected Version:
2.0rc3
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

I noticed a performance problem in Lighttable mode where there is a slow response while moving the mouse over a series of thumbnails.
For instance, moving the pointer over a series of 10 tumbnails took more than one second for the mouse-over selection to finish updating the thumbnail status and Image Information for the track the mouse pointer took.
In other words, screen updates were not fast enough to keep up with the mouse pointer.

However, the 2.0~rc3+108~g4ae6a1b-0pmjdebruijn1~trusty repository update I installed today seems to have made an improvement although there is still a little lag. Maybe this is not a bug anymore, but I thought it best to report it.

History

#1 Updated by Tobias Ellinghaus over 2 years ago

  • Status changed from New to Incomplete
  • % Done changed from 0 to 20

Please try disabling thumbnail color management in the 2nd tab of the preferences. That should speed it up a bit but might still be slow.

#2 Updated by John Morris over 2 years ago

Tried disabling thumbnail color management but it didn't seem to make a noticeable difference. There is much more lag in mouse-over response than I recall in 1.6.x.

#3 Updated by Stig Inge Lea Bjørnsen over 2 years ago

I'm experiencing a similar issue in Darktable 2.0 using Debian Sid. In the Lighttable, moving the mouse over the thumbnails or over the area below all the thumbnails generates a lot of CPU load.

When running Darktable with debug output, moving the mouse pointer one pixel as described above generates repeated output like this:

[lighttable] image expose took 0,0195 sec

followed by:

[mipmap_cache] thumbs fill 37,00/4096,00 MB (0,90%)
[mipmap_cache] float fill 0/8 slots (0,00%)
[mipmap_cache] full  fill 2/8 slots (25,00%)
[mipmap_cache] level | near match | miss | stand-in | fetches | total rq
[mipmap_cache] thumb |   0,36% |   0,18% | 100,00%  |   0,00% | 100,00%
[mipmap_cache] float |   -nan% |   -nan% |   0,00%  |   0,00% |   0,00%
[mipmap_cache] full  |   -nan% |   -nan% |   0,00%  | 100,00% |   0,00%

[lighttable] expose took 0,2182 sec

#4 Updated by Stig Inge Lea Bjørnsen almost 2 years ago

I have compiled from master@ca7497303b716f32e55fb9684ba4edeea1b8f6b2 using GTK 3.20 which has event compression enabled by default.

Both the lightroom view and the filmstrip at the bottom of the darkroom view are redrawn on every pixel the pointer is moved over them. This is the cause of the sluggishness.

Filmstrip

From src/libs/tools/filmstrip.c:

static gboolean _lib_filmstrip_motion_notify_callback(GtkWidget *w, GdkEventMotion *e, gpointer user_data)
{
  dt_lib_module_t *self = (dt_lib_module_t *)user_data;
  dt_lib_filmstrip_t *strip = (dt_lib_filmstrip_t *)self->data;

  strip->pointerx = e->x;
  strip->pointery = e->y;

  /* redraw */
  gtk_widget_queue_draw(self->widget);
  return TRUE;
}

Lighttable

Redrawing of the lighttable as the widget in the center is enqueued to `gtk_widget_queue_draw` by src/gui/gtk.c:

static void _ui_widget_redraw_callback(gpointer instance, GtkWidget *widget)

which is triggered by DT_SIGNAL_CONTROL_REDRAW_CENTER raised from src/views/lighttable.c:

void mouse_moved(dt_view_t *self, double x, double y, double pressure, int which)
{
  dt_control_queue_redraw_center();
}

which is called from src/views/view.c:

void dt_view_manager_mouse_moved(dt_view_manager_t *vm, double x, double y, double pressure, int which)

which is called from src/control/control.c:

void dt_control_mouse_moved(double x, double y, double pressure, int which)

which is called from gui/gtk.c:

static gboolean mouse_moved(GtkWidget *w, GdkEventMotion *event, gpointer user_data)

which is set to receive the motion-notify-event in gui/gtk.c:

int dt_gui_gtk_init(dt_gui_gtk_t *gui, int argc, char *argv[])

#5 Updated by Peter Grodovsky about 1 year ago

Hello, was there any development regarding this problem? Can I help by providing some more info? It really seems that lighttable is being redrawn constantly during mouse movement. Just moving the mouse around (even whithin the same thumbnail) generates over 200% CPU load for the darktable process (quad-core Intel i5-4590S CPU + 16GB RAM). This is on DT 2.2.3.

The experience is highly dependent on the window size and the size/number of thumbnails. This unfortunately makes lighttable almost unusably slow on a 4K display. Example debug (constantly repeated while the mouse moves) with a full-screen window on a 4096x2160 resolution, 6 thumbnails visible:

[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0394 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0420 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0397 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0491 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0122 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0499 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0072 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0133 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0148 sec
[mipmap_cache] thumbs fill 245,96/2048,00 MB (12,01%)
[mipmap_cache] float fill 0/4 slots (0,00%)
[mipmap_cache] full  fill 2/4 slots (50,00%)
[mipmap_cache] level | near match | miss | stand-in | fetches | total rq
[mipmap_cache] thumb |   0,35% |   0,10% | 100,00%  |  85,71% | 100,00%
[mipmap_cache] float |   -nan% |   -nan% |   0,00%  |   0,00% |   0,00%
[mipmap_cache] full  |   -nan% |   -nan% |   0,00%  |  14,29% |   0,00%

[lighttable] expose took 0,2704 sec

After resizing the window to roughly quarter of the screen (so about the size of standard full-hd display) the response is better, but the issue still persists:

[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0079 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0078 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0081 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0090 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0050 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0077 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0032 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0056 sec
[sql] /build/darktable-32pdEm/darktable-2.2.3/src/common/image.c:629, function dt_image_altered(): prepare "SELECT operation FROM main.history WHERE imgid = ?1" 
[lighttable] image expose took 0,0063 sec
[mipmap_cache] thumbs fill 245,96/2048,00 MB (12,01%)
[mipmap_cache] float fill 0/4 slots (0,00%)
[mipmap_cache] full  fill 2/4 slots (50,00%)
[mipmap_cache] level | near match | miss | stand-in | fetches | total rq
[mipmap_cache] thumb |   0,35% |   0,11% | 100,00%  |  85,71% | 100,00%
[mipmap_cache] float |   -nan% |   -nan% |   0,00%  |   0,00% |   0,00%
[mipmap_cache] full  |   -nan% |   -nan% |   0,00%  |  14,29% |   0,00%

[lighttable] expose took 0,0609 sec

It's worth noting that the response is very slow also when navigating with keyboard, not touching the mouse (and it depends on the window size as well). So maybe the constant redraw is not the only problem.

Thanks!

#6 Updated by Paolo Astengo 9 months ago

Is there any news about this ticket?

#7 Updated by Peter Grodovsky 4 months ago

Unfortunately the issue still persists in new darktable 2.4.0 - mouse navigation in lighttable consumes most of the CPU and is very lagging on a HiDPI display.

#8 Updated by ಚಿರಾಗ್ ನಟರಾಜ್ 2 months ago

Peter Grodovsky wrote:

Unfortunately the issue still persists in new darktable 2.4.0 - mouse navigation in lighttable consumes most of the CPU and is very lagging on a HiDPI display.

Yup, I just ran into this when I bought a new laptop. As a workaround, you can reduce your resolution, which should mitigate the issue.

As for an actual fix, what needs to be done and how can I help?

Also available in: Atom PDF