seanisom

7 ms·

1.
by seanisom 2y ago
This is pretty cool - great to see what a small codebase can do with raw WebGL. Have you looked at WebGPU at all?
2.
by seanisom 2y ago
Working fine for me on Firefox - their WebGL support tends to be good enough, although there are plenty of other resource issues.
3.
by seanisom 2y ago
This is awesome! The dev loop for web apps is kind of broken - really cool that you can keep this running in a browser.
4.
by seanisom 2y ago
Yes! You should be able to get nearly native performance for that sort of pipeline out of a WebGL backend.
5.
by seanisom 2y ago
Can you utilize streaming compilation of the Wasm modules? This significantly improved load times in Photoshop Web.
6.
by seanisom 2y ago
GPU processes are separated due to driver instability and unsafe code, so this means more than a GPU process crash, or a content process crash (tab crashed), something in the orchestration layer or main process crashed. There are probably m
7.
by seanisom 2y ago
Just wander itself is almost working in a browser - kind of hacked together right now, but will be pushed to the open-source soon. The same Wasm payload should be able to run in the browser or through wasmtime. For the rive-renderer /
8.
by seanisom 2y ago
Anybody remember COM? Yes, this is certainly not a new problem.
9.
by seanisom 2y ago
Keeping it high level - No, the goal is not to create a C++ API to give you GPU functions. The C++ API for wander is used to embed the WebAssembly module of graphics code into the application. The API footprint is very small - load a file,
10.
by seanisom 2y ago
Great suggestion, appreciate it. wgpu is coming!
11.
by seanisom 2y ago
More of a comment on how apps are being built in the future - web-first is becoming the default. I already see web even taking over in things like embedded UIs where native toolkits like QT historically were popular.
12.
by seanisom 2y ago
Appreciate it. It's coming! I want to get the compiler working and generally available and everything working seamlessly for Web first. Stay tuned!
13.
by seanisom 2y ago
Interesting! Had never heard of it before, will check it out. The point of Haxe seems to be as a meta-compiler to generate code for a bunch of different languages/compilers? The same spirit of the Wasm dev experience but without the ru
14.
by seanisom 2y ago
That's exactly it. With renderlet, the goal is to compile the "frontend" code that's driving the rendering pipeline to WebAssembly, and provide a runtime that embeds that in any app, with the host app providing any confi
15.
by seanisom 2y ago
This is awesome! I'm not fluent with Flutter/Dart but would like to dig in to how the build / Wasm packaging works. The state of shared memory for Wasm is not great, although raw SharedArrayBuffers work ok in a browser for ru
16.
by seanisom 2y ago
Not much yet! :) The renderlet is a bundle of WebAssembly code that handles data flow for graphics objects. Input is just function parameters, output writes serialized data to a specific place in Wasm linear memory. With the Wasm Component
17.
by seanisom 2y ago
I haven't worked with stereo setups with this codebase yet, but as it is just wrapping underlying platform-specific GPU APIs, it should be a similar performance profile. On average, running the Wasm guest code is about 80% of the speed
18.
by seanisom 2y ago
Lots of interesting points in there, and working on Bevy I'm sure you have much more extensive WebGPU expertise than me. I agree that the feature set around WebGPU is constrained and becoming outdated tech compared to native platforms.
19.
by seanisom 2y ago
> Currently it is the low level, cross platform layer that is the most complex and the biggest hurdle towards making a game engine viable I couldn't agree more. My goal is not to simply build "a better game engine", but to
20.
by seanisom 2y ago
Got it, thanks. Not what I was expecting. To me, this reads like the intersection of "Web Components as Wasm" and "The Browser as an OS" - almost something analogous to WASI as browser APIs that are delivered via Wasm AB
21.
by seanisom 2y ago
Thanks - that link does not appear to be open access, anyways I don't think I've seen it. I'm familiar with Flutter at a high-level (Kevin Moore gave a great talk on it at Wasm I/O), and I think other than requiring user
22.
by seanisom 2y ago
I think Godot is the closest thing to this today, and I agree, would love to work with them! Particularly on the Wasm and packaging side of things.
23.
by seanisom 2y ago
This right here. The web is the OS of the future - the standards are getting there, the tools are just starting to catch up.
24.
by seanisom 2y ago
I'm probably the worst person to ask for advice about applying to YC - it just kind of happened. I was sad when UE4 sunset HTML5 support, and glad to see a spiritual successor! There are a lot of parallels to other large in-browser app
25.
by seanisom 2y ago
This. I think it used to be a productivity power tool that they since incorporated into the core editor.
26.
by seanisom 2y ago
Interested as well - I think you've built an incredibly productive editor with Rive - a spiritual successor to Flash!
27.
by seanisom 2y ago
Hey Keavon, I'm also a big fan, been lurking in your Discord for years! The design of the render tree of Wasm nodes certainly took inspiration from Graphite's node system.
28.
by seanisom 2y ago
Great questions! The host app owns the event loop. I don't foresee that changing even once we re-architect around WebGPU (allowing the Wasm guest to control shaders), as the host app is responsible for "driving" the render tr
29.
by seanisom 2y ago
Big fan of Godot! I think it has done wonders to make graphics more accessible. From an Adobe perspective - it doesn't. If you go to photoshop.adobe.com in Safari, you will see the answer. Things can work in a single-threaded build, bu
30.
by seanisom 2y ago
Thanks! Lottie should be straightforward. SWF is a much higher bar, but would be useful.

More ›