Add a setting to cancel live jobs upon change #1248
Conversation
Current implementation of live mode will try to schedule jobs "sequentially": - the first change causes a job to be scheduled - we stop listening for changes until the job is finished - if the job wasn't for the latest change, a new job is scheduled, etc. This often results in having to wait for the intermediate results to complete, and is not always convenient. This change adds a setting, which, if toggled on, instructs Live mode to clear the queue and interrupt any running jobs upon receiving a new change, thus avoiding having to wait for intermediate results.
| # likely to be an out-of-order progress from cancelled/interrupted job so don't log these | ||
| pass | ||
| else: | ||
| log.error(f"Received message {msg} but there is no active job") |
There was a problem hiding this comment.
Not sure why are we logging these at all, especially at the Error level
|
There is some discussion about this in #628 The gist is that I'm not convinced cancel is a good idea, mainly because it means you have to actively restrain yourself from making any kind of change to avoid accidentally interrupting image generation when you don't want to. The basic idea of Live mode is that your are making small changes constantly and get (reasonably fast) feedback. If you find yourself waiting for results before continuing to work, the queued workflow or manual trigger via hotkey might be a better fit? I also have some issues with the implementation, usually there is a flow like this:
|
|
@Acly Thanks for the feedback!
After having worked with the plugin some more and getting used to it, I realize that this is a very important point. Even if the live generation takes a while (up to 4 seconds on my setup), it is still more meaningful for it to run sort of "in the background" while you are working uninterrupted. Regarding the suggestion to use a hotkey to generate: while I believe this might be a good workaround for very slow setups, I still consider it a very significant UX hit as these are additional actions you have to actively take, as opposed to simply keeping an eye on the preview panel. So, there are two potential improvements I see for the live generation process still:
|
No objections there. Easiest option would be just a configurable grace period. Possible extensions:
Might be nice even for people with very powerful setups to get the behavior when resolution is large, without losing responsiveness at low res. |
…on in live preview * This will prevent some of the "useless" generations, e.g. from the very start of the brush stroke * Period is configurable in settings; setting the default to 0 to preserve the existing behaviour This at least partially addresses/follows the discussions in Acly#628 and Acly#1248
|
Continued in #1412 |
…on in live preview * This will prevent some of the "useless" generations, e.g. from the very start of the brush stroke * Period is configurable in settings; setting the default to 0 to preserve the existing behaviour This at least partially addresses/follows the discussions in Acly#628 and Acly#1248
…on in live preview * This will prevent some of the "useless" generations, e.g. from the very start of the brush stroke * Period is configurable in settings; setting the default to 0 to preserve the existing behaviour This at least partially addresses/follows the discussions in Acly#628 and Acly#1248
…on in live preview (#1412) * Add a grace period between detecting a change and triggering generation in live preview * This will prevent some of the "useless" generations, e.g. from the very start of the brush stroke * Period is configurable in settings; setting the default to 0 to preserve the existing behaviour This at least partially addresses/follows the discussions in #628 and #1248 * Don't exit live generation loop when switching documents
Hi, thanks for this amazing plugin!
I've noticed an inconvenience with the way the jobs are scheduled in the live mode, and thought to contribute a fix I implemented for myself.
Current implementation of live mode will try to schedule jobs "sequentially":
This often results in having to wait for the intermediate results to complete, and is not always convenient.
This change adds a setting, which, if toggled on, instructs Live mode to clear the queue and interrupt any running jobs upon receiving a new change, thus avoiding having to wait for intermediate results.