Progress bar(s)

[Beep6581]

Originally reported on Google Code with ID 505

There are a few problems with the progress bar(s) in RT.

1- The first one, as described in issue 434, is that there is a separate progress bar
just to present thumbnail loading progress, and it's in a place where it doesn't really
belong. Why not just use the progress bar already present in RT to show thumbnail loading
progress while being in the file browser tab? http://i.imgur.com/ppPdO.jpg

2- The second issue, as I talked about with Hombre54 on IRC, is that our main progress
bar is useless most of the time (which is why I rated this issue as a medium priority
defect). The progress bar doesn't show the progress of the most time intensive tasks,
such as "high quality shadows/highlights" and "highlight reconstruction". In fact the
only thing it really does show is demosaicing progress. For everything else I found
it either doesn't respond at all, or not in any meaningful way, e.g. RT hangs with
the progress bar at 0% and then shoots to 100% when RT un-hangs.

3- The third issue is the placement of the progress bar. Compare these screenshots:
http://www.panopixel.org/drslony/images/screenshots/20101202_rt_gui_1.png
http://www.panopixel.org/drslony/images/screenshots/20101202_rt_gui_2.png
Hombre54 raised a point that if it were as in my mockup, it would be visible only when
the left panel is open. While true, I don't see this as a problem, because when we
do hide the panels ("m" shortcut) then we don't care about the progress bar, since
we can't do any editing.
As possible alternative locations for the progress bar, it could be moved to the bottom
of the right panel or right under the histogram in the right panel, but I don't like
that idea because the right panel is already always overflowing even on my 1080px high
screen. In fact the best place where it would always be visible even on a low resolution
is in the tab bar. However my favorite idea is to draw the progress bar as an overlay
over the image, only when its being used, in the lower-right corner, for example. It
would therefore always be visible when needed, and the fact that it disappears once
progress reaches 100%, something you can't not notice, would in itself serve as a signal
that processing is done (and the way it currently is, with the progress bar next to
the fullscreen button in its own toolbar at the bottom, is not enough, which is why
some users, myself included, have requested an audible notifier as well).

As an added bonus, we'd be getting rid of that horrid www.rawtherapee.com url :]

Reported by entertheyoni on 2011-01-22 16:01:59

[Beep6581]

2) It's true ... in the code there are a lot of points where information should go to
the progressBar, but aren't, for different causes.
I'm trying to have an overall view ... the progress fro 0-100% should be consistent
when applying any change, and is not.
I'm thinking also if the red/green led is really usefull, or could be superseeded by
a progress bar for all the processing of the current photo, maybe in the same position.
I'm wondering what is the best position: if next to the GIMP button (now there is a
lot of space), or on top right next to tabs (see point 3)

3) Agree for the bottom strip that is not really exploited; the problem is GTKmm 2.16.
If we'd use 2.22 ... here is little patch to try.

Reported by ffsup2@yahoo.it on 2011-02-06 10:38:16

---

• _Attachment: ProgressBar_1.diff_

[Beep6581]

Agreed progress bar is underutilized.  On the other hand, let's not go overboard.  I
found one time (I think it was when implementing fast demosaic) that too fine a gradation
of the progress bar was slowing down the processing, as the calls to send a change
to the display were interrupting the image processing itself.

Reported by ejm.60657 on 2011-02-06 13:37:41

[Beep6581]

No need for a LED if you have a working progress bar and audio feedback.
There still is not space next to the gimp button on a 1024x768 display (our minimum
resolution requirement). There is lot's of space in the tab bar, as well as under the
Snapshots add/del buttons, as in the second mockup.

Too fine is one thing, jumping from 0 to 100%, and then still hanging for a few seconds,
is another.

Reported by entertheyoni on 2011-02-07 00:20:40

[Beep6581]

Progress bar visibility is not very good in some themes; this is where led helps at
present.

Reported by michaelezra000 on 2011-02-07 00:58:25

[Beep6581]

I quite like the led; I hate programs that bombard me with beeps and ringtones and cute
little ditties.  And there is often a lag between when the progress bar ends and the
led lights up indicating the program is ready, and I find that feedback useful.  Also
many tasks do not indicate on the progress bar, and for them the only feedback is the
led or a beep, and I prefer the led.

Reported by ejm.60657 on 2011-02-07 03:51:48

[Beep6581]

humm, I'm a new user of RT and most of the few runs I did were on very extreme conditions
(I mean, I was using RT on a netbook... you know, travel :) )
Well, this is to say that RT behaves pretty well on a 1024x600 screen, except a few
waste of space including this progress bar.

So please keep this little Led indicator I really love, because it quickly shows if
the user has control or not. Ideally it should appear green when the program is ready
and red when the preview is updating because of a processing job. This could be extended
to a third state (orange ?) when the process queue is running so the led never really
return to the green when CPU is working hard.
Also this Led should be moved in the bottom bar, ideally against the fullscreen button,
to lighten the overloaded "zoom" bar as showed here: http://www.panopixel.org/drslony/images/screenshots/20101202_rt_gui_1.png

This is a suggestion I posted there because I don't want this thread to be place where
the decision was taken to suppress this lovely led indicator I really miss in most
of softwares, including bibble (you know applying a noise processing that takes tenths
of seconds makes me, and probably you I'm sure, sticking eyes on the screen to be sure
the image preview has been updated ;) )

Reported by rom1dep on 2011-02-23 14:21:44

[Beep6581]

Another relevant issue:

Issue 547: Progress-bar displays "Ready" in the middle of the process

Prog.

Reported by prognathous@bluebottle.com on 2011-03-03 16:28:11

[Beep6581]

My idea is not to delete the led, but to substitute it with a colorfull progress: red
at start, green (or better) gray when done.
At present the status indication is not perfect, several steps performed in background
are not shown; it's hard because the code that prints is scattered.
I'd want to sum all infos related to the currently edited photo into a central evident
widget... and maybe move the standard progress that would show only image loading next
to the tab ( as in the first patch )

Reported by ffsup2@yahoo.it on 2011-03-03 20:52:37

[Beep6581]

In response to previous posts: the fact that (currently) the progress bar almost never
works properly is not an argument for the LED being a better solution.

The LED serves the same purpose as the progress bar, only the progress bar is more
useful, it can convey more information than the LED - such as estimated time till completion,
number of images already processed (progress bar overlaid text), as well as a much
more visible indicator.

The LED is small. This is a problem when you stare at the preview waiting for it to
update with a minute change (e.g. demosaicing, or some kind of noise reduction), and
the led is so small that your peripheral vision cannot discern with certainty whether
it changed colors, especially if you've been staring for a while now. Not so with the
progress bar, it's big and clear.

The LED "quickly shows if the user has control or not". So does the progress bar (we're
assuming its fixed to work properly).

"This could be extended to a third state (orange ?) when the process queue is running
so the led never really return to the green when CPU is working hard." Your "simple"
LED is becoming less and less simple :] The progress bar can convey this info and more,
and more clearly.

"you know applying a noise processing that takes tenths [typo, i think you meant "tens"
-- DrSlony] of seconds makes me, and probably you I'm sure, sticking eyes on the screen
to be sure the image preview has been updated ;)"
Exactly! And the progress bar is better suited for this. Not only is it bigger and
easier to discern, but it can also indicate how much you have to wait, so you don't
stare at the same spot without blinking like an idiot for half a minute as I sometimes
do :]

What's more, the LED, despite being currently more reliable than the progress bar,
isn't without fault either. Try saving an image directly, bypassing the queue. Both
the LED and progress bar are useless. The only indicator that your image has been saved
is the save button itself that becomes un-grayed once the file has been written.

Color propagation reports useful information into the console. You can see how many
iterations are left, more or less.

Reported by entertheyoni on 2011-03-03 23:50:28

[Beep6581]

Here is a patch to show the idea; some details need to be improved.
Apply to default tip.

Reported by ffsup2@yahoo.it on 2011-03-04 22:00:33

---

• _Attachment: ProgressBar_2.diff_

[Beep6581]

I love where this is going!
Of course it needs to use colors from the gtkrc profile and so on, but the visibility
of the progress bar, the placement of the progress bar and of the buttons, and the
small rearrangement of the interface are beneficial to RT.

Reported by entertheyoni on 2011-03-05 00:39:06

[Beep6581]

I agree, this is very good! Thanks for your efforts!
Regards,
Johan

Reported by johan.andersson@sodra.com on 2011-03-05 06:45:22

[Beep6581]

Issue 547 has been merged into this issue.

Reported by ffsup2@yahoo.it on 2011-03-05 08:07:36

[Beep6581]

Fabio, this is a nice improvement, thank you! The larger red label and its disappearance
is much easier to notice than the led! 

I observe a coupe of issues.
In the vertical tab layout the width of the tabs "Editor", "Batch Queue" and "File
Browser" is very large due to placement of a progress label & preference & fullscreen
icons. One solution could be to rotate progress bar and pref & fullscreen icons 90
degrees for vertical tab layout. 

It would be more intuitive, however, if there was only a single progress bar, also
retaining the red coloring during progress.

Reported by michaelezra000 on 2011-03-05 12:45:28

[Beep6581]

Yes, I forgot vertical tab layout: it has some problems, I'll fix it.
I feel two progress are a little reduntant, but they shows two different kind of operations;
think for example at multitab-mode. Also please, test saving an image or sending to
Gimp to see the effect.
Note: to delete bottom status bar, gtk 2.20 or higher is required! So, in case you
like this new layout, compilation requirement have to be modified too.

Reported by ffsup2@yahoo.it on 2011-03-05 13:36:50

[Beep6581]

Luckily, I am using GTK 2.2:)

Reported by michaelezra000 on 2011-03-06 13:59:36

[Beep6581]

Improvements in the progress bars display.
Added thumbnails browser link to top progress bar; added number of files information
(filtered/total) in the tab.
Corrected vertical tab mode (unluckily gtk can't show vertical text on progress bar)

Reported by ffsup2@yahoo.it on 2011-03-12 23:06:54

---

• _Attachment: ProgressBar_3.diff_

[Beep6581]

Thanks Fabio, this works great!

Reported by michaelezra000 on 2011-03-13 14:58:09

[Beep6581]

If is OK, I'll apply to default branch.
If there are some quirks in the progress, please report here.

Latest patch contains also a partial fix for previewloader:  previewsFinished() were
called once for each pool thread instead of only once at the end, but there is a problem
left: if exception throws (for example error in profile loading), the thread that loads
the thumb exits.

Reported by ffsup2@yahoo.it on 2011-03-14 18:25:07

[Beep6581]

Applied to default with some more improvements (also added translations)

Reported by ffsup2@yahoo.it on 2011-03-17 16:24:32

• Status changed: PatchApplied

[Beep6581]

Great, this also fixed issue 556

Reported by michaelezra000 on 2011-03-17 20:42:26

[Beep6581]

To delete the "fixed in code" "Red color"...

Would be better to change gtk themes to have progressbars a little more evident, but
I have any clue on this (:-(

Reported by ffsup2@yahoo.it on 2011-03-25 18:23:09

---

• Attachment: DeleteRedColor.diff

[Beep6581]

Issue 239 has been merged into this issue.

Reported by entertheyoni on 2011-06-27 12:05:37

[Beep6581]

Referring to point 2 of my initial post:

As implementing proper progress bars is a problem, would it be possible to at least
keep the progress bar in the processing state (red color in current builds) until everything
has indeed finished, especially things like color propagation? Reason being that color
propagation can keep grinding data long after the progress bar has reported that it
has finished processing, and then suddenly the preview gets updated when you thought
RT wasn't doing anything. A temporary hack/workaround would be much better than leaving
it as it is.

Reported by entertheyoni on 2011-06-27 12:10:51

• Status changed: Started
• Labels added: Component-UI, Usability
• Labels removed: Milestone-3.1

[Beep6581]

No, color propagation (if you are referring to the patch not yet in default) indicates
100% just before exiting the code.  What you are likely not seeing indicated is all
the other processing that takes place between highlight reconstruction and image display,
which is everything that takes place post-demosaic, including processing of crops for
the preview window.

Reported by ejm.60657 on 2011-06-27 12:44:35

[Beep6581]

Would it be possible to keep the progress bar in the processing state till all that's
done?

Reported by entertheyoni on 2011-06-27 13:16:46

[Beep6581]

What is needed is for somebody to go through the various steps in the pipeline and insert
some progress bar updates like I did in hilite_recon.cc.  I may do it if I find time.

Reported by ejm.60657 on 2011-06-27 13:44:48

[Beep6581]

progress bar was messed up when defloat branch was merged: I discovered some days ago,
some changes i did before were lost.

Reported by ffsup2@yahoo.it on 2011-06-27 18:01:59

[Beep6581]

Here is a quick and sloppy version, I'm sure someone who is better with the UI could
do better...

Reported by ejm.60657 on 2011-06-27 18:18:52

---

• Attachment: progress.patch

[Beep6581]

There is a progress per tool, which is informative and interesting to view, especially
for getting a sense of the time each stage of the processing takes, but there is no
indication of the global progress % spanning all tools.

After applying this patch and editing an open image progress bar primarily displays
message "Lab curves" when editing RGB exposure tools. I am curious - why?
Also, "Lab curves" flashes two times (no 100% detail windows open).

There is a change to dcrop.cc in this patch (unfortunately, I have no idea what it
does:) ), is this intentional?

Reported by michaelezra000 on 2011-06-28 02:12:56

[Beep6581]

Issue 249 has been merged into this issue.

Reported by entertheyoni on 2011-06-30 23:01:13

[Beep6581]

Thank you, I will test it tomorrow.

Reported by entertheyoni on 2011-06-30 23:02:00

[Beep6581]

The patch works well enough Emil, thank you. I shouldn't have posted three problems
in one issue, so I will start a new issue for general long-term progress bar improvements
as related to point 2 in my first post.

Reported by entertheyoni on 2011-07-02 21:22:26

• Status changed: Verified

[Beep6581]

Reported by rinni@gmx.net on 2013-01-28 14:31:30

• Status changed: Fixed