stop shouldn’t ever “beachball” - it feels unnatural. Ideally, whatever non-trivial shutdown tasks it needs to perform can be offloaded without actually showing the user.
The stop button shows a progress bar by design. Say you have a composition with a node that takes a long time to execute. You press the stop button while that node is executing. When you press stop, the composition waits for nodes to finish, then quits. The stop button’s progress indicator reflects the fact that it’s waiting for the composition to finish and quit. It would be inaccurate to pretend as though the composition had stopped before it actually does.
For a start → solid layer → render layer to window graph, it’s unclear why it takes a non-trivial amount of time to stop. for file I/O or network requests, sure, stopping taking a while makes sense (similar for an actually expensive computation graph), but it seems a little too “accurate”.
Alternatively, the interpretation is ambiguous. If I click stop, it’s ambiguous if I want to trigger a graceful stop (the current implementation), or a hostile “kill the process” stop – waiting for a pathological graph seems troublesome (FillTheHarddriveWithZeros node, or DownloadTheInternet node, for example), so I can see cases for either. Not sure of a good clutter-free design for that though :(
For a start → solid layer → render layer to window graph, it’s unclear why it takes a non-trivial amount of time to stop.
Ah, good point. On my system, it takes about 1 second. And I think I found what’s causing that delay. I’ll try to get that fixed.
Fixed in Vuo 1.2.0 — the Stop button now works without noticeable delay (unless the composition needs time to finish something before it quits, like finalizing a movie export).