Prevent Redundant Live-Preview

[Haoming02]

Description

• Simple Description: Currently, the condition of whether to generate a preview is solely based on the current step count. Depending on the settings (ie. show_progress_every_n_steps and live_preview_refresh_period) and parameters (ie. steps), you may waste resources generating an extra preview that you would never be able to see anyway.

  eg. Generate a total of 30 steps, with show_progress_every_n_steps set to 4. At step 28, you only have 2 steps left to see the preview. If your system is fast enough, you won't see the preview; even if you do see the preview, there's rather little point in interrupting with only 2 steps left anyway...

• Summary of Changes: Add a new condition to check if the remaining steps is larger than show_progress_every_n_steps still

Checklist

• I have read contributing wiki page
• I have performed a self-review of my own code
• My code follows the style guidelines
• My code passes tests

[w-e-w]

if I understanding and test is correct this would cause issues in certain situations

example
if I need too frequent levepreviews then I would set opts.show_progress_every_n_steps like 10
let's say if my sample steps size is 20
with you PR
it will skipped the preview of the last step as it would basically saveing some time as the last preview is not really necessary

BUT
if my sampling step is 19 and `opts.show_progress_every_n_steps set to 11

then this would cause it to never be updated as the the first at 11/19 alread triggers the condition of (remaining steps < show_progress_every_n_steps), I would think I would want to see the live preview at 11/19

particularly if the job takes very long slow computers or working on a big image
they might want some live previews just not that frequent
in these cases haveing a preview at around 50% is it's good enough for them to judge if they wish to cancel the generation, as the later 50% may take another 5 minutes

---

extra info

the current system works a differently depends on if you're in --low-vram mode

if you are NOT in --low-vram in the preview image is only decoded when the front end webpage you are asked for it, upon request it will decode the latent in parallel
during sampleing the latent latent it is just stored

With --low-vrammode the latent is decode on the every setp specified steps in series
which would significantly slow down generation