Any options for efficient (and maybe synchronous) Rust to Dart callbacks?

[bnord01]

My goal is to use a rust library inside the Flutter UI loop. I want to register callbacks with the library that then will update the UI. The events are themselves triggered by other UI events that call rust functions.

I have two issues with this, the first is technicality as the library only allows me to register synchronous callbacks, which is somewhat a pain as FRB only allows asynchronous callbacks. I worked around this using a StreamSink.

This however leads to the second problem: Very poor performance in the browser. I created a very minimal test app to drag a widget on a canvas and handle the position update through a rust callback.

This is already very choppy. It starts smooth but randomly the callbacks start to pile up and are only handled every few seconds.

Is there an efficient way to do this using FRB? I tried manually spawning tasks to call a callback and other things. The behaviour is always the same.

I really love the developer experience of FRB compared to js-interop (which we use currently and is a big pain). However the same use case runs buttery smooth using js-interop and I'm struggling to find a way to do this using FRB.

Test Code for Reference

Rust

use flutter_rust_bridge::frb;
use std::{collections::HashMap, sync::Mutex};
use crate::frb_generated::StreamSink;

lazy_static::lazy_static! {
    static ref CALLBACKS: Mutex<HashMap<String,StreamSink<(f64, f64)>>> =  Mutex::new(HashMap::new());
}

#[frb(sync)]
pub fn observe_box(id: String, callback: StreamSink<(f64, f64)>) {
    CALLBACKS.lock().unwrap().insert(id, callback);
}

#[frb(sync)]
pub fn move_box(id: String, x: f64, y: f64) {
    if let Err(e) = CALLBACKS.lock().unwrap().get(&id).unwrap().add((x, y)) {
        log::error!("Could not send observation of {id}, {e:?}");
    }
}

Flutter

import 'package:flutter/material.dart';
import 'package:frb_test/src/rust/api/provider.dart';
import 'package:frb_test/src/rust/frb_generated.dart';

Future<void> main() async {
  await RustLib.init();
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Draggable Boxes',
      home: Scaffold(
        appBar: AppBar(
          title: const Text('Draggable Boxes'),
        ),
        body: const DraggableBoxes(),
      ),
    );
  }
}

class DraggableBoxes extends StatelessWidget {
  final double _boxSize = 100;

  const DraggableBoxes({super.key});

  @override
  Widget build(BuildContext context) {
    return Stack(
      children: [
        DraggableBox(id: "blue", boxSize: _boxSize, color: Colors.blue),
        DraggableBox(
            id: "red",
            boxSize: _boxSize,
            color: Colors.red,
            initialX: 150,
            initialY: 150),
      ],
    );
  }
}

class DraggableBox extends StatefulWidget {
  final String id;
  final double boxSize;
  final Color color;
  final double initialX;
  final double initialY;

  const DraggableBox({
    super.key,
    required this.id,
    required this.boxSize,
    required this.color,
    this.initialX = 0,
    this.initialY = 0,
  });

  @override
  DraggableBoxState createState() => DraggableBoxState();
}

class DraggableBoxState extends State<DraggableBox> {
  late double _xPosition;
  late double _yPosition;
  double _dragX = 0;
  double _dragY = 0;

  @override
  void initState() {
    super.initState();
    _xPosition = widget.initialX;
    _yPosition = widget.initialY;
    observeBox(id: widget.id).listen((event) {
      setState(() {
        _xPosition = event.$1;
        _yPosition = event.$2;
      });
    });
  }

  @override
  Widget build(BuildContext context) {
    return Positioned(
      left: _xPosition,
      top: _yPosition,
      child: GestureDetector(
        onPanUpdate: (details) {
          _dragX += details.delta.dx;
          _dragY += details.delta.dy;
          moveBox(id: widget.id, x: _dragX, y: _dragY);
        },
        onPanStart: (details) {
          _dragX = _xPosition;
          _dragY = _yPosition;
        },
        child: Container(
          width: widget.boxSize,
          height: widget.boxSize,
          color: widget.color,
        ),
      ),
    );
  }
}

[fzyzcjy]

the library only allows me to register synchronous callbacks, which is somewhat a pain as FRB only allows asynchronous callbacks

It seems we can do e.g.

onPanUpdate: () {
  myRustFunction();
}

even if myRustFunction is async.

Very poor performance in the browser

Maybe firstly try to run in profile/release mode, i.e. ensure both Rust and Dart are compiled in release (instead of debug). This can have many performance differences iirc.

[bnord01]

Hi, thanks for the quick response!

Concerning release mode

Maybe firstly try to run in profile/release mode, i.e. ensure both Rust and Dart are compiled in release (instead of debug). This can have many performance differences iirc.

Compiling & running both Rust and Dart in release mode yields some performance improvements but it mostly makes the already smooth parts smother, the reoccurring stuttering and piling up of callbacks remains.

Concerning async callbacks

Sorry, I should have stated this clearer. The issue is the other way around. The Rust library I want to use is synchronous and accepts synchronous rust callbacks to observe changes. Imagine something like:

trait Library {
    fn observe(&self, on_change: impl Fn(Event));
    fn update(&self, update: Update);
}

The callback on_change should update the Flutter UI so ideally I would want to pass a Dart function as a callback to Rust. However in FRB such a callback has to be an asynchronous impl Fn(A) -> DartFnFuture<B> which can't be called directly from a synchronous callback like on_change called by the library.

Workarounds I tried:

• Spawning a new thread using spawn/spawn_local to call and await the Dart callback. (stuttering behaviour)
• Using the above mentioned StreamSink. (stuttering behaviour)
• Using a Tokio unbounded channel with a non blocking send and a worker thread to call the Dart callback. (stuttering behaviour)
• Using a Tokio bounded channel with a blocking send. (send_blocking panics: PanicException(EXECUTE_SYNC_ABORT RuntimeError: Atomics.wait cannot be called in this context )

[fzyzcjy]

the reoccurring stuttering and piling up of callbacks remains.

Ok then that's a problem.

Could you please do some profiling (iirc chrome has some good ones) to see is it

a. CPU is fully running, thus it is because the code occupies all CPU and is really slowwwwww
b. CPU is quite idle, thus looks like somewhere there is unnecessary stucked

However in FRB such a callback has to be an asynchronous

Yes, because IMHO your rust code could be in non-main thread, thus calling Dart will have to be async.
On the other hand, if you guarantee your Rust code to be on main thread, maybe we can develop something to make it sync. But note that then your Rust code will block the main ui thread, maybe causing it to be janky if rust is computation heavy.

However in FRB such a callback has to be an asynchronous impl Fn(A) -> DartFnFuture<B> which can't be called directly from a synchronous callback like on_change called by the library.

Usually it is just spawn. Anyway, spawn and streamsink ultimately just send data to a dart Port, so the underlying mechanism is the same.

[fzyzcjy]

I am still wondering why that would be janky... Could you please try to make a minimal reproducible sample? Then maybe it will be easier to see what is going wrong.

[bnord01]

Could you please try to make a minimal reproducible sample?

I wrapped the above code into an runnable example here: https://github.com/bnord01/frb-callback-ui-slow-mwe

On the other hand, if you guarantee your Rust code to be on main thread, maybe we can develop something to make it sync.

If the synchronous Dart callback handed down to the Rust code by FRB would not be Send the Rust code could only call it from the thread that originally passed it down.

I hope this helps, thanks for the effort!

[fzyzcjy]

I wrapped the above code into an runnable example here: bnord01/frb-callback-ui-slow-mwe

Looks good! So maybe we can do something to debug it

• As mentioned above, look at chrome's devtool to see whether it is realy using full cpu, or something else
• print (e.g. print current time ms) or use other ways at each critical location, to know what part takes a long time

If the synchronous Dart callback handed down to the Rust code by FRB would not be Send the Rust code could only call it from the thread that originally passed it down.

I guess so