Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pause render hotkey #6104

Open
wants to merge 4 commits into
base: 1.5_maintenance
Choose a base branch
from
Open

Conversation

ericmehl
Copy link
Collaborator

This adds Escape as a hotkey to pause the render, as well as pausing the viewport updates (which was already the behavior). It also adds a hotkey, Control + \, to pause and start the render. Both need to have the viewer as the focus widget.

Finally, aiming to match the hotkey behavior, I added a commit to unpause the viewer when the play button is pushed.

I tested this with Arnold, adding a high number of subdivisions to the Gafferbot meshes. Pausing worked fairly well - it still takes a few seconds on my machine to get it to pause. We're already using Arnold's AiRenderInterrupt() which from their documentation sounds like the most appropriate method for what we want to do.

It seems like that needs to wait for the current batch of meshes to finish subdividing, then it pauses. Adding more subdivisions increases the time it takes for Arnold to pause.

There's also the issue of pausing the render before the renderer actually begins. Talking yesterday about this, that would require shifting some scene processing to a background thread so the UI thread is unlocked. We discussed that being a follow-up to this PR rather than including it now.

Checklist

  • I have read the contribution guidelines.
  • I have updated the documentation, if applicable.
  • I have tested my change(s) in the test suite, and added new test cases where necessary.
  • My code follows the Gaffer project's prevailing coding style and conventions.

@tomc-cinesite
Copy link
Contributor

This will be really useful, thanks @ericmehl. In case it is relevant, we have a ticket on our side to auto-pause all renders and scene expansion when a free-memory lower limit is reached. The idea being to avoid killing your machine if you accidentally expand all on a scene of significant complexity. Wondered if there would be any interest in a more public API for managing 'ongoing expansion/rendering tasks' without needing to know the specifics of the particular view implementations, etc.

@johnhaddon
Copy link
Member

We did toy with the idea of a global panicSignal() that all pauseable things could connect to, and which you could trigger from your memory monitor. I don't know if Esc would emit that, or if it would continue to just pause the thing that received the keypress. Any thoughts?

@tomc-cinesite
Copy link
Contributor

I don't know if Esc would emit that, or if it would continue to just pause the thing that received the keypress. Any thoughts?

Quote of the day that summarises it nicely:

I would love it. Esc = I’m freaking out stop it all. But I never freak out. Still need ESC to prevent the freak out.

@ericmehl ericmehl changed the base branch from main to 1.5_maintenance October 28, 2024 13:58
@johnhaddon
Copy link
Member

@tomc-cinesite, do you think it's worth taking a bit more time on this to make the "universal panic signal" thing, or is this worthwhile enough in its own right? We don't think the signal represents a lot more work - say a day maybe?

@tomc-cinesite
Copy link
Contributor

@tomc-cinesite, do you think it's worth taking a bit more time on this to make the "universal panic signal" thing, or is this worthwhile enough in its own right? We don't think the signal represents a lot more work - say a day maybe?

Its pretty high on our list to make a big red help button for people and connect it to a memory watcher. So if you happend to feel so inclined as to make us a lovely panic API method we can call and hook ESC up to it, that would certainly make our lives easier 🙏

Thanking you most kindly.

@ericmehl
Copy link
Collaborator Author

ericmehl commented Nov 4, 2024

@tomc-cinesite I'll probably roll the global pause signal into this PR to help get your memory watcher feature off the ground.

A few questions about what you would find the most useful. When the signal is emitted (by pressing the Escape key most likely) :

What should be paused? IPR renders for sure. And everything else too? Hierarchy views, scene inspectors and primitive inspectors, among others, can all trigger high resource and memory usage so we're thinking those should get paused.

How would you want to get out of the paused state? We're considering an un-pause button on the script window that would end this global paused state. That way we wouldn't need lots of un-pause buttons throughout the UI that all need to be pushed.

Would you want the global un-pause button to leave IPR renders (the ones that were paused as a result of the global pause signal) paused, or un-pause them?

And I expect it would be desirable to apply this application-wide, so it would pause things in all open scripts. Would pressing un-pause apply to the window holding the button only, or to all open script windows in the application session?

Thanks for any advisement you can offer!

@tomc-cinesite
Copy link
Contributor

@ericmehl Excellent questions. Per-script please! Making unpause unpause all the things that it paused all together would be 👌 Thanks so much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: On the Radar
Development

Successfully merging this pull request may close these issues.

3 participants