Support for new rive_native rendering engine

[bajabob]

Problem to solve

As per: rive-app/rive-flutter#461 (comment)

rive_native appears to be the new rendering engine for flutter. It supports rendering functions that were missing previously. For example: Feathering is supported in rive_native.

Source: https://rive.app/docs/runtimes/flutter/rive-native#key-differences-between-rive-native-and-rive

Proposal

Is there a plan to move to this in the future? Or should flame developers be working on a custom integration at this time?

More information

No response

Other

• Are you interested in working on a PR for this?

[spydon]

Do you know if the new rive renderer can be used on the normal Flutter canvas?
My guess would be that it can't, but I'm not sure.

[bajabob]

Do you know if the new rive renderer can be used on the normal Flutter canvas? My guess would be that it can't, but I'm not sure.

My understanding is yes, it can.

From the docs (source):

Rive Native is a new runtime that enables you to display and interact with Rive graphics in your Flutter app, powered by the Rive Renderer.

You can pull down the example app, and it has plenty of Rive examples that render in flutter.

Source is not published yet, but you can pull them down anyways using this Get Started tutorial. I captured the above screenshots after testing it out locally on my M4 Pro Macbook Pro.

[NashIlli]

+1

[bcz5678]

+1

[naychrist]

The new rive renderer does not use flutter canvas, it uses it's own render texture. In the pictured demo you can optionally run it with the old flutter/canvas renderer instead but you won't get the performance improvements. When creating a new rive painter you can override a function that makes a call to paint to canvas after drawing to the render texture but that's not of use for rendering the rive assets themselves.

I am currently using the new renderer with flame manually using the rive dev release package. I do this with a rive render texture on top of the flame drawn canvas. I have flame components that have a rive paint function that I then call manually from another components update function to draw them on top. Not ideal as I need to manage render priority and layering myself but is working. I have one project where I use canvas for the BG and rive for sprites, although a current project is using rive for the BG as well.

would love to know what the flame plan for this is going forward.

[spydon]

@naychrist thanks for the insight!
There is no current plan for how to move forward with flame_rive, but if anyone has a good idea for how we could do this we're all ears.

[NashIlli]

@spydon
We’re exploring support for a renderer that draws to its own GPU texture (not Canvas) and want to understand whether Flame has a realistic path to fully integrate this into the scene graph (position/scale/rotation, camera transforms, lifecycle, layering).

Could you share what you see as a viable direction for this? If there’s a path you consider reasonable, we’re happy to try an initial PR and target the integration points you suggest.

For context: we’ve been developing projects that pair Flame with Rive up to now, and we’d love to keep building on both. If the roadmaps diverge at the renderer level, we may need to choose one stack for future projects—so your view on a feasible path would help us plan.

[spydon]

@NashIlli for priority (z-index) to work with a custom GPU texture I think the full component system would need to be rendered to that texture. In the team we have previously discussed the possibility of have an abstract canvas interface so that other rendering systems can be used instead of the built-in Flutter canvas.

[NashIlli]

@spydon thanks!

This sounds like a substantial architectural shift for Flame. If you’re able, could you elaborate a bit on the team’s thinking so far around the “abstract canvas” direction and how you see it playing out in the medium term? Any high-level view on feasibility and likely approach would help us plan—and we’d be glad to align and contribute once there’s a direction.

[spydon]

This sounds like a substantial architectural shift for Flame.

I don't think it necessarily has to be, the only difference for the user would be that they optionally can pass in another canvas instance to GameWidget that can be used instead of Flutter's canvas.

how you see it playing out in the medium term?

For v1 it would need to be a non-breaking change, so that the canvas passed in to GameWidget would need to implement the dart:ui Canvas.
You could try to just swap out the canvas here and see if it works:
https://github.com/flame-engine/flame/blob/main/packages/flame/lib/src/game/game_render_box.dart#L127-L130

It would of course be quite a lot of work for the one implementing another canvas implementation though.