Minor performance upgrade: Don't update histogram while still computing

[rekcodocker]

Describe the bug

I notice the histogram is updated during computation, and then again when computation is finished.
To save CPU cycles it should be updated when the entire pipeline is finished.

Note: This happens when you initially load a picture for the first computations that involve the entire pipeline. After that the results of the first modules are probably cached.

Steps to reproduce

1. Load an image into the darktable.
2. Rotate the image.
3. Note how the histogram updates twice - once during the computation and once when finalized. I use the waveform and I see the ends dip as if vignette correction has not been applied. After a moment when rotation is finished it straightens itself again.

Expected behavior

DT should update the histogram only once at the end of the pipeline.

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

4.7.0

What OS are you using?

Linux

What is the version of your OS?

Linux Mint

Describe your system?

not really relevant

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

intel HD 600

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[jenshannoschwalm]

I think what we do is correct, it's due to taking histogram and pickerdata for each preview pixelpipe run and in the described case we run it in fast and in standard mode resulting in different data so we have to update each time. (We want to provide meaningful output also while one of those "expanding modules" like crop, ashift ... is active/expanded).

[rekcodocker]

Ok so it can be explained why it works this way.
That does not make it correct from a user perspective and it does not negate the fact that CPU performance is used for nothing.

From a user perspective you see the histogram flip and twist and then correct itself - and only once. It doesn't do it the next time.
That gives a user no information to act upon or do anything with.

The only thing it means to a user can do is gain some insight: apparently the pipeline collects this information and updates the display, apparently the output of mutliple runs is cached (as it happens only once).

But 'technically interesting' is not 'actionable information'
No user needs this information or can do anything with it. It's just a quirk. Explainable but not needed.

[jenshannoschwalm]

ok, if you think this is a big issue for any user go ahead with coding! (You also see the image re-displaying partly while developing so what is this issue about?)

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[ralfbrown]

In addition to the multiple pipes, the scopes module also gets update requests from the GUI update code - which is a mess. expose() in views/darkroom.c gets called on any widget update and then proceeds to repaint the entire darktable window (including telling any open processing modules to refresh their displays, which caused an infinite refresh loop with liquify that I recently fixed).

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.