UI/Web: Reduce animation of default --progress_bars setting to improve speed

[one-lithe-rune]

Addresses #1457

Motivation

There is small but noticeable difference in generation speed between running with the UI minimized and with it not, in favor of the minimized case. This is also seen if you size the app or browser window such that the gallery showing generated images is outside the browser viewport.

In addition, currently the no-progress_bars command-line option doesn't appear to improve speed after the first image in the batch, I'm guess something changed with the upgrade to gradio 3.34.0 there.

All these looks like they are being caused by the two CSS animations that are run by gradio during generation, the 'sweep across the gallery' animation you get during the first image generation of a batch, and the 'pulsing border' animation you get on both the gallery and the generation status text box. This latter one happens even when you have --no-progress_bars set.

Code Changes

• Use the "minimal" setting for show_progress in gradio functions when the (currently default) --progress_bars option is set. This removes the 'sweep across the gallery' animation. You still get the textual progress indicator in the top right corner of the gallery.
• Remove the pulsation animation from the border of galleries and generation status textboxes for both --progress_bars and --no_progress_bars settings. The orange color is retained.

Measured Generation Speed Changes

All these are using the same prompt and other settings from the UI using SharkEulerDiscrete, on an SD 1.5 based model, ui=web, Firefox browser on Windows 10:

Txt2Imge without changes:

h768 x w512 (--progress_bar)
50it [00:04, 10.02it/s]
50it [00:04, 10.03it/s]
50it [00:04, 10.01it/s]
50it [00:04, 10.02it/s]
50it [00:04, 10.01it/s]
50it [00:05,  9.97it/s]

h768 x w512 (--no-progress_bar)
50it [00:04, 10.34it/s]
50it [00:05,  9.98it/s]
50it [00:05,  9.95it/s]
50it [00:05,  9.93it/s]
50it [00:05,  9.96it/s]
50it [00:05,  9.93it/s]

Txt2Img with changes:

h768 x w512 (--progress_bar)

50it [00:04, 10.28it/s]
50it [00:04, 10.31it/s]
50it [00:04, 10.31it/s]
50it [00:04, 10.30it/s]
50it [00:04, 10.31it/s]
50it [00:04, 10.32it/s]

h768 x w512 (--no-progress_bar)

50it [00:04, 10.28it/s]
50it [00:04, 10.29it/s]
50it [00:04, 10.27it/s]
50it [00:04, 10.26it/s]
50it [00:04, 10.27it/s]
50it [00:04, 10.29it/s]

[NeedsMoar]

It is in fact consistent now (I'd not tested in a while). I reverted to an older driver version so I could get tuned numbers.

--no-progress_bar
h768 x w512
60it [00:04, 13.05it/s]
60it [00:04, 13.19it/s]
60it [00:04, 13.14it/s]
60it [00:04, 13.19it/s]
60it [00:04, 12.95it/s]
60it [00:04, 13.11it/s]

Default (--progress_bar, I think)
60it [00:04, 13.21it/s]
60it [00:04, 13.07it/s]
60it [00:04, 13.17it/s]
60it [00:04, 13.20it/s]
60it [00:04, 13.22it/s]
60it [00:04, 13.24it/s]

Although the progress bars don't actually show up anywhere either way (haven't for a while) so I'm not sure what the flag does anymore. I believe this model is sd1.4 based but other than that there isn't much difference.