AuburnSounds / AuburnSounds/Dplug
Drop onAnimate frames when dt is too small
- Dominant language
- D
- Stars
- 564
- Forks
- 34
- PR merge metrics
- No merged PRs in 30d
Description
Making a limit of accumulated 20ms before calling onAnimate can save CPU at little visual cost.
Could be a counter inside UIElement that is checked before calling onAnimate (eg: 20ms).
- [x] Do we want that UI-wide, or for each single UI Element? => I don't think it makes sense UI-wide
- [x] What's the use case? It can be "no short animation steps" or "fixed animation step" => no short animation steps is kinda more needed
- [x] At the same time, a global time measure on animation CPU cost can be helpful too. => much less so that (say) a flame graph that show widget display cost
Use case 1:
Note: high feedback plugins may want to synchronize feedback in the same sync queue, in order to minimize scheduler lock (exiting a tryLock is a heavy operation anyway). And then it is helpful to have onAnimate for children called just after main gui.d onAnimate. Such a UI might need both "do not animate for low dt" and "animated with fixed dt" at the same time, and will batch setDirty calls likewise.
Contributor guide
Research direction
The issue names UIElement and onAnimate but no files or tests; begin by locating those entry points and reading how animation timing is currently propagated. Clarify the per-element accumulation, the 20ms threshold, and interaction with fixed animation steps before implementation; done means the agreed behavior is covered by relevant tests.
Written by the indexing model from the issue text.
Assessment
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100