`update_smooth` blocks with `sleep`
See original GitHub issueUsing update_smooth
will slow down your program. Every time you call it, you add 5 ms to your program execution per percent of progress. It should be non-blocking to have an use case.
One idea would be to have the bar in its own thread and have the context manager hide the ugly thread details from the user, keeping the same or similar interface.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
Frequently Asked Component Specific Questions - TMS Software
Update smooth controls faster with BeginUpdate and EndUpdate. This short article describes the use of BeginUpdate and EndUpdate methods ...
Read more >sleep() method behavior in synchronize block - Stack Overflow
A synchronized method implicitly synchronizes on this . In your case the instance of ThreadRunnable . But each thread has its own instance ......
Read more >Technical Alpha Update - Smooth Sailing | MMORPG.com
The Sea of Thieves team has posted a new update to the ongoing Technical Alpha that provides new information about additional features being...
Read more >VanderMock 3.0: Getting defensive - Houston Texans
You're thinking 'What? We just drafted Clowney and we still have Whitney Mercilus!' But Clowney is coming off a very tough injury and...
Read more >bolt/CHANGELOG.md at master · boltdesignsystem/bolt - GitHub
... update path to action-block subcomponent, add test to confirm subcomponent renders (17bd150) ... reducing previous debugging sleep command ([e09115e](; ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Threads will increase complexity for sure and fighting race conditions can be difficult but as the project is in such an early stage, it might be quite doable to architect for that.
Alternatively, one could use a delta time approach to keep the printing operations in the main thread but have the timer in a background thread, using that as the progress value between the previous and the target percentage. Then you could also quite easily give the user the option to configure the animation duration. Just have to handle multiple overlapping calls somehow, perhaps by updating the target percentage, and then setting the current time in the timer to the delta calculated from previous progress so the animation just continues on with the new settings 🤔
I think there’s also ready-made solutions for tweening but you still need a time value but without a concrete update loop, a thread is needed to implement that update loop independent of main. (I think)
Food for thought 😄
I have tested and pushed the changes to the master branch, closing this issue as completed.