rive-app / rive-ios

iOS runtime for Rive
MIT License
468 stars 53 forks source link

Support >60fps #247

Open rdavisau opened 1 year ago

rdavisau commented 1 year ago

Is it possible to run animations at frame rates above 60 on devices that support it?

I have tried setting riveView.preferredFramesPerSecond = UIScreen.main.maximumFramesPerSecond;, and the include the required CADisableMinimumFrameDurationOnPhone key in info.plist. On a device with 120fps support, CADisplayLink frame rate is 120, so it is possible for the app to display content at that rate. However, the ~'rive debug overlay'~ 'Metal Performance HUD' shows that the animation runs at 60fps.

image
sgade commented 10 months ago

I observed this in our app as well. It is a problem because our animation is shown in a scroll view which can increase the display refresh rate up to 120 Hz. Setting the animation's frame rate from 60 to 120 didn't change anything. It is still rendered at 60 FPS maximum.

CADisplayLink has a targetTimestamp property which should be used instead of getting the current Date's timestamp. Still, the rendering is limited to 60 FPS. Is that a restriction of the underlying framework implementation? If so, why?

SilverTab commented 9 months ago

+1 on this... It would be great to see a response or at least an acknowledgement from someone at Rive about this. Is it working as intended and we're doing something wrong? Is this a known issue that's being worked on?. As it is, it's basically impossible for us to use a rive animation in a ScrollView, which is turning out to be a big blocker for our adoption of Rive 😞

marcus-hobbs commented 9 months ago

Hi @caudetgit . I emailed a minimal sample project created by @SilverTab that illustrates this problem to support@rive.com . We hope your team finds it helpful in debugging this issue. We'll monitor this issue for updates.

caudetgit commented 9 months ago

Hi folks. We think we have a solution. It's working with SwiftUI, and we're fixing an issue in UIKit. We hope to be able to share the updated package early next week.

marcus-hobbs commented 9 months ago

@caudetgit That's fantastic...thanks for working on this. It will really improve the quality of the experience for our users.

caudetgit commented 8 months ago

Hi all. Please take a look at the latest package 5.5.1 for an update that enables CADisplayLink to run at a user-defined preferredFramesPerSecond. The bulk of the change was in 5.5.0, but we fixed a small issue in 5.5.1.

You'll also need to add CADisableMinimumFrameDurationOnPhone=true to your info.plist

Note that preferredFramesPerSecond API is marked as deprecated by Apple, and we still need to understand what the alternative is https://developer.apple.com/documentation/quartzcore/cadisplaylink/1648421-preferredframespersecond. But the potential alternative preferredFrameRateRange is in beta and no documentation is yet available.

marcus-hobbs commented 8 months ago

thank you @caudetgit . We'll test this.

sgade commented 8 months ago

I tested it with 5.5.1 and the new Info.plist key. Seems to work fine. Didn't have to set the preferred fps at all.

Although the preferredFrameRateRange property has no documentation, it seems to replace the preferredFramesPerSecond property. I would assume that you supply your minimum and maximum supported FPS. According to the documentation around CADisplayLink, it has always been the case that you can prefer a certain FPS but the system has the ultimate control over the actual frame rate. Factors that contribute to different frame rates are scrolling on ProMotion displays, if the system is in low power mode (limiting to 60 FPS on those displays AFAIK), etc.

The new property might give the system more leeway while it is more clear to developers that we might strive for 60+ fps but that the animation might also be running in a 30 fps environment. The renderer should then adapt to save power.

marcus-hobbs commented 8 months ago

@caudetgit our internal testing: looks good! we'll start rolling it out to users next week.

caudetgit commented 8 months ago

@marcus-hobbs Thanks for confirming!