Offscreen Canvas Support for WASM about three-d HOT 5 CLOSED

First of all, it sounds like a really good idea 👍
As I understand it, the only problem is in canvas.rs Window struct? The purpose of the desktop and web window setup code was purely as a way to make it easy to start a new project. It was never the intention to have a window setup with a lot of features. That would just distract the focus from the rendering features which is the main purpose. However, it would be really nice that most users do not have to create their own custom window setup, so for example passing in a web_sys::canvas at creation time is a really good idea and if offscreen rendering only requires the addition of avoiding some global calls, then that should be investigated as well (I tried really quickly and it seems doable, but not super quick to do).
Anyway, you are welcome to try to change canvas.rs and make a pull request if you succeed or you can create your own window setup and just use the rendering features. In the latter case, I will take a look at it at some point.

from three-d.

Hi, and thanks for the feedback.
Yes exactly. My idea basically would be to provide an even more "lightweight" version of the canvas.rs Window struct.

I'm not super deep into the code of this crate, but I imagine a API roughly somewhat like this:

// user's code to setup the canvas/webgl context (could be via web_sys directly, or some other way
let websys_window = web_sys::window().unwrap();
let document = websys_window.document().unwrap();
let canvas =
    document.get_element_by_id("my-special-canvas").unwrap();
let canvas: web_sys::HtmlCanvasElement = canvas.dyn_into::<web_sys::HtmlCanvasElement>().unwrap();

let canvas_context = canvas.get_context_with_context_options("webgl2", &JsValue::from_serde(&context_options).unwrap()).unwrap().dyn_into::<WebGl2RenderingContext>().unwrap();

// or with the offscreen use case, the same api can be used as long as the user of the crate can somehow get a WebGl2RenderingContext
let offscreen_canvas: web_sys::OffscreenCanvas = canvas.transfer_control_to_offscreen().unwrap();

let canvas_context = offscreen_canvas.get_context_with_context_options("webgl2", &JsValue::from_serde(&context_options).unwrap()).unwrap().dyn_into::<WebGl2RenderingContext>().unwrap();


// new api, maybe it makes more sense to creata an additional struct
// since this wouldn't really be a window anymore, more a struct for managing the rendering target and handling the rendering loop etc...
let window = three_d::Window::new(canvas_context);

let context = window.gl();

// the window would still handle the render loop
window.render_loop(move |frame_input: FrameInput| {

    Screen::write(&context, &ClearState::color_and_depth(0.8, 0.8, 0.8, 1.0, 1.0), || {
        // render something
        Ok(())
    }).unwrap();

    FrameOutput::default()
});

// as this new window would not have access to the canvas itself
// the user will need to setup settings like setting the device pixel ration, width/height
// and also update them if they change
window.update_size(newWidth, newHeight);

I guess this new Window Struct (or whatever the new API would be) will have very little logic inside it besides the rendering_loop logic

from three-d.

No problem and thanks for your suggestions 🙂
I totally understand if you don't have a full overview, but you are actually totally right. The Window struct has two purposes. First it needs to create a window and the related context (webgl2renderingcontext on web). This is what you have set up manually in the code above. The second thing is the render loop which is just a loop which feeds information about events and screen size to the rendering. Nothing wrong with creating a simple loop yourself especially if you don't need to handle events. So I think the web Window in canvas.rs just needs to be a bit more flexible, no need to create a new struct that does the same thing. A thing which is fairly straightforward (the Window api is quite simple https://docs.rs/three-d/0.6.1/three_d/window/struct.Window.html even though it contains quite a lot of code). I will think about how to do it while keeping a simple API which works on both desktop and web (which is not necessarily an easy task). But just to make it clear, I had always thought that people would make their own versions of the Window structs so the rest is completely independent of the Window and should work no matter where you are rendering as long as you have a Context https://docs.rs/three-d/0.6.1/three_d/context/type.Context.html.

from three-d.

@kije So I will add support for specifying the canvas directly soon and I will also make a function to have access to the canvas. However, I don’t think offline support in the Window struct makes much sense. The setup, as you say, is completely different so that should be the work of the user. That leaves the render loop, but what is that used for in an offline context? You don't even have a way to update the render loop since the requestAnimationFrame function is on the window. And what events should be handled if the user can’t see the canvas? I hope you get my point 😄 You can of course use an offline context together with a window, which is why I will add access to the canvas from which you can create an offline canvas and transfer the result back to the original canvas.
So just to make everything clear, you can render to a canvas without using a Window and a render loop at all, just make a context from the canvas as done in the Window and you can start rendering.
Does it make sense or did I miss something?

from three-d.

Canvas setter and getter in c520884

from three-d.