Can leptos draw graphics on canvas?

[xtrn143]

Hi everyone, I really want to know if leptos can manipulate H5 Canvas to draw graphics, just like using JS to draw on Canvas.Are there any similar examples？

[gbj]

Yes.

It really has very little to do with Leptos though, and everything to do with the underlying wasm-bindgen and web-sys crates that power the whole Rust/WASM web ecosystem.

I'd recommend starting with the canvas guides in the wasm-bindgen docs and going from there. You can easily get access to an HtmlCanvasElement from a Leptos NodeRef on a <canvas> in the view.

[s1n7ax]

@xtrn143 Were you able to draw on canvas? Any code samples?

[gbj]

https://rustwasm.github.io/docs/wasm-bindgen/examples/2d-canvas.html

[kakserpom]

https://gitcommitsuicide.com/matrix

[s1n7ax]

I guess I was looking for more of a step by step tutorial. Coming from js and some of these things are not obvious. With little bit of luck, I got working as expected.

1. First add web-sys with feature CanvasRenderingContext2d because leptos does not include that I guess? I was clueless when I couldn't find that CanvasRenderingContext2d

[dependencies]
web-sys = { version = "0.3.55", features = ["CanvasRenderingContext2d"] }

2. Use deref to get web-sys element from leptos wrapper (I guess)

#[component]
pub fn Spider() -> impl IntoView {
  let canvas_ref = create_node_ref::<html::Canvas>();

  create_effect(move |_| {
    if let Some(canvas) = canvas_ref.get() {
      let width = canvas.offset_width() as u32;
      let height = canvas.offset_height() as u32;

      canvas.set_width(width);
      canvas.set_height(height);

      let html_canvas = canvas.deref();

      let ctx = html_canvas
        .get_context("2d")
        .unwrap()
        .unwrap()
        .dyn_into::<CanvasRenderingContext2d>()
        .unwrap();

      ctx.set_fill_style(&JsValue::from_str("red"));
      ctx.begin_path();
      // what ever you want to do with the canvas
      ctx.fill();
    }
  });

  view! {
    <canvas node_ref=canvas_ref class=styles::canvas />
  }
}

[gbj]

@BugsSoren I'm confused by both these comments: the Leptos request_animation_frame helper just wraps a Rust function and calls the web-sys one, but it shouldn't behave differently.

Leptos does not have types called AnimationContext or AnimationSignal.

I just wanted to clarify for the sake of avoiding confusion.

[BugsSoren]

@gbj Hmm can't find the AnimationContext or AnimationSignal again. Might have been in undocumented source code or another crate in my hunt for a solution. I often use grep on source code when doing research. So forget that one.

I began by making the assumption that Leptos merely wrapped the web_sys request_animation_frame. The fundamental difference is that Leptos expects the callback to be FnOnce, where the web_sys version expects Function which can be constructed as either Fn or FnMut. Generally Leptos prefers FnOnce because they are more convenient to write. However, a FnOnce consumes its environment where Fn and and FnMut do not. When using request_animation_frame both JavaScript and web-sys use a recursive function that calls itself. I couldn't find a way to do that using FnOnce.

A year or two ago a created a test crate using pure web-sys (pre-dates my preference for Leptos) to draw animation to a . As I recall, I followed an example in web-sys docs or forum, but I might be mistaken. From that code:

    let app = App::new();
   //persist data used inside animation callback
    let app = Rc::new(RefCell::new(app));
    let app3 = app.clone();
    //use Rc<Refcell>> to persist callback
    let f = Rc::new(RefCell::new(None));
    //make a clone and assign callback closure
    let g = f.clone();
    *g.borrow_mut() = Some(Closure::new(move || {
        let mut app = app3.borrow_mut();
        log::debug!("raf");
        //recurse the loop using original f
        request_animation_frame(f.borrow().as_ref().unwrap());
    }));
    //start the loop using the g clone
    request_animation_frame(g.borrow().as_ref().unwrap());

The callback is wrapped in a Rc<RefCell>> to persist it. Using f and g allow the closure to be used inside itself and starting from outside.

The wasm_bingen docs for Closure shows an example for using a FnOnce with Closure::once, but that is not recursive. The recursion would need to be done externally in a loop. For that I would need to spawn a separate task and animation might not be as consistent. Plus this uses wasm_bindgen macros to wrap functions, which probably wouldn't work inside Leptos. I tried
using Closure::once with the Rc<RefCell>> approach and mostly got compiler errors for "infinite size" when creating the callback.

Fundamentally, I don't know how to create a persistent FnOnce that isn't consumed with usage. In most cases Leptos docs show using forget() to make closures persistent, which creates a memory leak and is a lazy coding pattern that will likely come back to bite you.

Rather than wasting more time, I went with using web-sys, since I already had a working example. In the end it was kind of a mute point because the callback runs outside the Leptos reactive graph context and web-sys canvas context methods are used for drawing. No real advantage to using Leptos here and it made more sense to make the entire canvas module web-sys rather than a hybrid. I took some inspiration from the 'leptos-bevy-canvascrate for setting up my component. They usedcrossbeam-channelfor communication. However, looks like I can use Leptosget_untracked()` to poll signals inside the animation loop, but I might need to use mpsc channels yet. I forgo some of the niceties of Leptos because the animation loop can't receive Leptos signal notifications, but its better for animation when done with polling at times when drawing permits.

Probably < 1% Leptos to glue UI and drawing together and 0% if I use mpsc. A future project direction may take this client-server-client with separate clients for UI and drawing. Keeping drawing as a isolated module will make that easier.

I have my test animation working. Next step is to get Leptos UI to provide property changes to modify drawing. When I get things more polished, I will try to publish an example crate on GitHub and/or crates.io.

[gbj]

The fundamental difference is that Leptos expects the callback to be FnOnce, where the web_sys version expects Function which can be constructed as either Fn or FnMut. Generally Leptos prefers FnOnce because they are more convenient to write. However, a FnOnce consumes its environment where Fn and and FnMut do not.
...
I don't know how to create a persistent FnOnce that isn't consumed with usage.

I think there might be a misunderstanding here: every Rust function implements FnOnce. Some of them also implement FnMut, and a smaller subset implement Fn. Taking impl FnOnce for something that's only going to be called once is the most permissive/flexible API.

That said, the actual code we're talking about is quite short (50 lines, mostly comments). It uses .into_js_value(), which does not leak memory when compiled with support for weak references (which has been the wasm-bindgen default for a while now)

I agree that you do not need to use any of these small helpers that Leptos provides, and that directly using web-sys may be more useful for your project. I just want to provide some clarification about the word of caution you're offering here, to avoid misleading anyone else reading this in the future.

[BugsSoren]

You're explanation of FnOnce vs FnMut vs Fn is much clearer than mine, in that not every FnOnce is also Fn or FnMut.
Which was exactly what my problem was getting a persistent Fn passed to request_animation_frame() when using the helper.
In the typical approach to a callback to request_animation_frame() the callback is a recursively called persistent Fn or FnMut. It is not called once and disposed of (or its environment), it must persist to be called recursively.

Let leave it at the consensus of the thread is, drawing and animation to are best done directly with web-sys. This is not something Leptos itself provides beyond the re-exporting of web-sys. Maybe my caution should have been limited to advising to avoid using the Leptos provided helper since it is not needed or useful when using web-sys directly and can lead to issues that I experienced.

I also see the suggestions for using forget() for closures and the potential for memory leakage has since been removed from the Leptos book. I remembered that from my early usage of Leptos when the book was very immature. Or maybe from another
framework I was experimenting with in the past. Many things have improved with the 0.7 release.

[KySpace]

It works! Thanks!