-
Notifications
You must be signed in to change notification settings - Fork 10
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
Move animation management out of Engine #95
Conversation
dc998b1
to
d07dd37
Compare
This moves responsibility for tracking animations and switching to next/previous animations out of the various paintables and into a single location
All animations have an initial render delay of 0ms for their initial frame.
d07dd37
to
7f5d16c
Compare
Completely removes config functions from Engine
Changes state into a struct and improves the config update function
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take another look at this PR tomorrow. Just a couple more comments until then.
Allows instant access to a given index without modifying or traversing lists
wait, why was this closed, I haven't had a chance to look yet! |
I was able to have a chat with @vanvoljg offline. This PR was on track to merge and didn't have any blockers, so I think we can reopen it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff! 🎉
Here, animation loading, state, and management are pulled out of
RGBMatrix.Engine
and into theXebow
application. This separates a few concerns to where theEngine
only has to deal with rendering,RGBMatrix.Animation
handles functions related to animations themselves, andXebow
handles creating the list of animations, initializing animations, switching animations, and persisting config modifications in memory.This should make it easier to introduce other application controlling logic such as animation activation/deactivation, configuration persistence between reboots, and eventually runtime discovery/installation of animations (which are currently hard-coded into the animation module).
This PR also fixes the black frame on live view creation, and removes the 0-ms
render_in
that was returned by all animations on callingnew/2
. Animations which need to delay the render of their first frame could set the first frame to black, have an internal state that determines how long to wait, and check that state in itsrender/2
callback functions.addresses part of #49, but leaves open a bunch of questions aboutruntime discovery of animations, enabling/disabling, etc.
closes #80
closes #83