aurelienpierreeng / ansel

A darktable fork minus the bloat plus some design vision.
https://ansel.photos
GNU General Public License v3.0
669 stars 21 forks source link

No feedback during export #252

Open pedrorrodriguez opened 9 months ago

pedrorrodriguez commented 9 months ago

When you export an image, the app provides info on two States: "exporting", and "exported". In lower end computers there is no way of knowing if the pipeline is just heavy, or the computer froze. A progress bar with a percentage would be great.

aurelienpierre commented 9 months ago

There is a progress bar for multiple exports. Synchronizing the progressbar with the pipeline progression would make the export even slower.

pedrorrodriguez commented 9 months ago

There is a progress bar for multiple exports. Synchronizing the progressbar with the pipeline progression would make the export even slower.

Well.. Sort of. It adds a third state and tells you image 1 of n is finished. I don't have a solution to this problem, but an export progress bar is pretty much ubiquitous in any software, from web browsers, to image editors, video editors, 3d software, DAWs... It is useful to know if your image is just taking longer to export because of a heavy pipeline or if your computer froze.

Also, if you cancel the export, you no longer get the exporting image 1/1. You just get "exporting image", which doesn't give you any more confidence that your computer is not freaking out.

aurelienpierre commented 8 months ago

To solve:

  1. in pixelpipe_hb.c, in dt_dev_pixelpipe_process_rec(), map the pos argument to a completion coeff,
  2. the function calls itself recursively from the end of the pipe, with pos = number of modules in pipe (typically, 83), until pos == 0, meaning we load the raw buffer into pipeline,
  3. store initial_pos = pos at the first call, then progress is computed from pos / initial_pos when running each module process() or fetching input buffer from cache. But the caching vs. processing anew paradigm makes it hard to tell if, for a given pos, we are currently processing or only calling the module (n - 1)
  4. find a way to communicate the current valid pos / initial_pos completion coeff to the GUI thread updating the progress bar. Doing so in a thread-safe way, taking into account that not all exports have a GUI and therefore a GUI progress bar, is going to be unreliable and prone to segfaults with current code.

TL;DR: a serious clean-up is needed before even thinking of implementing that.

aurelienpierre commented 2 months ago

The mandatory serious cleanup was completed today.