Deno WGPU context access in embedded rust runtime

[wanton torrent]

Looking to bind the WGPU context to a windowing library like winit . I've seen modules that implement similar solutions using FFI but my architecture spec requires rust to orchestrate the application lifecycle. Would appreciate any advice to point me in the right direction. Anyone have experience working with embedded deno in a similar fashion?

[regal loom]

just to get a clearer idea: you are trying to make a windowing system, right (ie electron, but with webgpu)? or is this something else?

[wanton torrent]

That's the gist of it

[regal loom]

this is currently not possible

its something thats being investigated as there is interest from me and someone else on the team for a windowing solution (as per #dev-desktop)

[wanton torrent]

Ah, that's understandable. I've been following the topic on windowing in deno. Is there a specific hurdle I should be aware of that's making the windowing solution non-trivial?
My plan B is to create extension ops bindings to expose rust open gl rendering functionality as a global api that conforms to the WebGL spec.

Anything worth considering before I get ahead of myself?

[regal loom]

the main hurdle is that deno_runtime cannot be extended, which is fairly crucial, and is something that has been worked on for quite a while and unsure how long thats going to take until thats possible.

regarind your plan B. that could work, though you'd still encounter the deno_runtime problem (except if you use deno_core, but thats kinda... eh)

[wanton torrent]

I think I might give creating a POC with deno_core but can you elaborate on the...'eh'? Rust has taught me to embrace patience and pain for the privilege to work in an ecosystem that's empowering bleeding edge solutions.

[regal loom]

deno_core means that it wouldnt have any of the other APIs, and would have to pull in all other exts to give an experience similar to CLI (but not all APIs are available as exts, some APIs are only available in deno_runtime)

[wanton torrent]

ah, that's something I should look into. With that said, my end goal is to implement react-three-fibre and Three.JS rendering for windowed applications. Hopefully that minimises dependency budget from the deno std lib.

Luckily I have a reference project to essentially just translate to rust https://github.com/expo/expo/tree/main/packages/expo-gl

[novel vine]

few libraries you can look at

[regal loom]

oh interesting, never heard of react-three-fibre. there actually is a planned project by someone in the community to do use webgpu (with obviously some higher-level abstraction) via jsx

[novel vine]

@forest edge has some really good deno webgl implementation stuff

[wanton torrent]

react-three-fibre is the basis of amazing modules by the PMNDRS team (developers of zustand, jotai, react-spring) that extend Three.js with crazy functionality and a DSL that makes graphics rendering feel natural composable. Highly recommend taking a look at their work.

It's what https://spline.design/ uses. But their desktop app is built with electron and 'someone needs to make them feel bad that'

[wanton torrent]

Ooo just added his deno_gl repo to my reference implementation collection. Might be worth having a yarn with @forest edge before I reinvent the wheel

[novel vine]

it's a pain to write

[regal loom]

and using webgl in the emerging age of webgpu sounds painful

[novel vine]

yeah it is

but writing bindings is more painful

[novel vine]

time to write a flash renderer

in pure js that readers in the terminal

I'm going insane I need sleep

[wanton torrent]

The advantage of using react-three-fibre and only patching the react reconciliation root means components written to render on the desktop can be used for react-native and the web by default.

With the state of webgpu support across browsers, I wouldn't see myself taking advantage of webgpu for the foreseeable future.

It's definitely going to hurt... a lot but if the crab gods are on my side - I think it would be a worthwhile step towards making graphics rendering on the desktop more approachable for frontend developers

[regal loom]

With the state of webgpu support across browsers, I wouldn't see myself taking advantage of webgpu for the foreseeable future.
I agree, which i find quite sad

[wanton torrent]

I don't know though, if you'd advise against the binding approach I can table the idea until deno_runtime is more open

[regal loom]

i think its a more "you do you" scenario; the main downside with deno_core is that you have to implement the fs APIs yourself, which is something that i'd say is quite important when doing graphic rendering, as you often want to use some sort of texture

[wanton torrent]

After 16 years of chasing exciting ideas to develop, I have learned that it is wise to defer to subject matter experts and stable conventions before getting ahead of myself. That's not say I didn't have fun really doing me with PHP and javascript before Typescript. I did some terrible things with jQuery... good times

[wanton torrent]

The FS API is definitely something I can't justify implementing with the scope of the solution. I think that's definitely something worth waiting for the grown ups to let me play with

[regal loom]

well, if we are lucky, extending deno_runtime should be possible in the coming days/weeks

[novel vine]

remember when wgsl completely changed its syntax a few times

[novel vine]

in what way

[regal loom]

what do you mean?

[novel vine]

like wgsl tends to change its syntax alot

importing shaders in deno would be cool for debugging

[regal loom]

How is that related to extending deno_runtime?

[wanton torrent]

Oh, nice! I'll be looking forward to seeing the release pop up in my GitHub feed. Loving the release frequency

[remote minnow]

Check out https://github.com/astrodon/astrodon as well

[novel vine]

i forgot

what did you mean

[novel vine]

i like astrodon

[wanton torrent]

The developer Marc is an absolute operator. I forgot astrodon embeds deno, I'll pick his brain about his implementation and link any sage advice

[icy stag]

hi, that's me

Feel free to ask me any question, the only issues I had with Astrodon is that there are a few features from Deno that are implemented in the CLI so embedding deno_runtime will not give you the entire power, some of them can be reimplemented but it's still not the same thing

[novel vine]

you seem familiar

[icy stag]

I am everywhere!

[novel vine]

well that's true

[forest edge]

yeah deno gl works pretty well just that the webgl implementation isn’t much complete

so you want to do windowing via deno’s webgpu?

is the goal to embed deno?