Encountering significant script execution time on StateMachine.advanceStateMachine and StateMachine.getReportedEventCount

[postmemetic]

We have a scene in which we are sometimes displaying several animating characters at once on a UGUI Canvas set to worldspace render mode. On modern desktop computers with fast CPU's, we are encountering significant CPU usage resulting in framerate drops from 60 to 40 with around 10 characters on-screen. On iOS and Android, we are seeing far worse results, with noticeable slowdown even on 3 or so characters. The majority of CPU time is spent within two function calls to the native libraries:

StateMachine.advanceStateMachine specifically hits high CPU usage during LateUpdate

StateMachine.getReportedEventCount spikes CPU usage during Update

We are observing the issue with the current Unity package release (0.3.9-canary.57), as well as with the latest tag (v0.3.9-canary.170), which we pulled down manually and integrated for performance comparison tests.

[damzobridge]

We currently advance on Unity’s main thread, so if a lot of work is happening each frame, you may see slowdowns. We’re working on an update that will let you move that work to a separate thread, which should help in heavier scenarios.

That said, there’s also some per-widget overhead to consider. Since you’re rendering this inside a 2D canvas, I’m curious why you’re creating multiple RiveWidgets instead of handling everything inside a single widget using list-item instantiation with databinding. Keeping everything in one file/widget allows the Rive runtime to manage instances more efficiently and apply internal optimizations that aren’t possible when each element is a separate widget because they have different contexts.

On a related note, Rive Events are generally discouraged in favor of databinding, which lets you observe property changes with fewer allocations and less overhead.

Finally, would you be able to share the .rev file? (You can send it privately if you prefer.) It looks like a significant amount of work is happening every frame, and I’d like to see what’s going on inside the graphic itself.

[postmemetic]

We currently advance on Unity’s main thread, so if a lot of work is happening each frame, you may see slowdowns. We’re working on an update that will let you move that work to a separate thread, which should help in heavier scenarios.

That said, there’s also some per-widget overhead to consider. Since you’re rendering this inside a 2D canvas, I’m curious why you’re creating multiple RiveWidgets instead of handling everything inside a single widget using list-item instantiation with databinding. Keeping everything in one file/widget allows the Rive runtime to manage instances more efficiently and apply internal optimizations that aren’t possible when each element is a separate widget because they have different contexts.

On a related note, Rive Events are generally discouraged in favor of databinding, which lets you observe property changes with fewer allocations and less overhead.

Finally, would you be able to share the .rev file? (You can send it privately if you prefer.) It looks like a significant amount of work is happening every frame, and I’d like to see what’s going on inside the graphic itself.

I appreciate the fast reply! I'll pass you a copy of the file once I've gotten permissions. In the meantime, I'll look into some of our implementation choices and see if we can adhere to some better practices. I believe some of our assets were created before we had locked down our workflow and maybe before some platform features were in a mature state.