Darktable: Prevent user interactions while pipe is recomputing

[aurelienpierre]

Is your feature request related to a problem? Please describe.
Zooming and changing parameters values in darkroom is allowed even when the pipe is recomputing, triggering a new recomputing, and can loop into a never-ending spree of recomputations if user gets impatient.

Describe the solution you'd like
Block every interaction while the pipe is not finished recomputing, and display a waiting cursor.

Piece of code to add:

if(cursor_valid) // cursor is on window
  {
    if(dev->pipe->processing ||
      (dev->image_status == DT_DEV_PIXELPIPE_DIRTY) ||
      (dev->preview_status == DT_DEV_PIXELPIPE_DIRTY) )
    {
      // display waiting cursor while pipe reprocess or will soon
      GtkWidget *widget = dt_ui_main_window(darktable.gui->ui);
      GdkCursor *cursor = gdk_cursor_new_from_name(gdk_display_get_default(), "wait");
      gdk_window_set_cursor(gtk_widget_get_window(widget), cursor);
      g_object_unref(cursor);
      dt_control_queue_redraw_center();
      return; // break interaction callback
    }
    else
    {
      // reset default cursor
      GtkWidget *widget = dt_ui_main_window(darktable.gui->ui);
      GdkCursor *cursor = gdk_cursor_new_from_name(gdk_display_get_default(), "default");
      gdk_window_set_cursor(gtk_widget_get_window(widget), cursor);
      g_object_unref(cursor);
      dt_control_queue_redraw_center();
    }
  }

  // process user input

I'm not sure where to add that though.

[rawfiner]

I would advocate to interrupt computation instead, to launch it again as soon as possible, but this would be much more complicated to code.
As an example, when denoising an image, I usually change several parameters at once (for instance, patch size and scattering in nlmeans). Having to wait in between any change would make my workflow a bit slower. Yet, having the first process interrupted and relaunched as soon as a parameter change would make the waiting time shorter.

[rawfiner]

I would advocate to interrupt computation instead, to launch it again as soon as possible, but this would be much more complicated to code.
As an example, when denoising an image, I usually change several parameters at once (for instance, patch size and scattering in nlmeans). Having to wait in between any change would make my workflow a bit slower. Yet, having the first process interrupted and relaunched as soon as a parameter change would make the waiting time shorter.

[parafin]

IMHO it's a very bad idea which will make GUI very annoying to use if heavy modules are in use or user's system is not very powerful. Also it's conceptually very wrong, GUI has to work asynchronously to any computations, and you are basically blocking it making GUI synchronous.

[TurboGit]

I agree with parafin.

[Nilvus]

I also agree with rawfiner. Anyway, recomputing again and again should be improved. I don't know how difficult it could be code that but I'm more on the rawfiner way if possible.

[pitbuster]

Blocking the UI is terrbile UX, I would also advocate for cancelling the current computation (I thought that that was the current behavior).

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 7 days if no update occurs. Please check if the master branch has fixed it since then.