Skip to content

Consider the trade-offs of swapping to a native WebGPU renderer instead of using WebViews #80

@rdw-software

Description

@rdw-software

So far the whole WebGPU thing is just an experiment. In order to determine whether it's an actually viable approach, some of the trickier elements that come "for free" (not really, but that's another story...) in a WebView and especially with BJS should be evaluated:

  • HTML/CSS based UI: An alternative would be RML, for which I've yet to build a prototype - consider animations, events, blending
  • Performance evaluation: Rendering a complex scene with many objects, e.g. the old BJS sprite instancing benchmark
  • Rendering ambient and directional light sources: This may not be too difficult, but who knows... dynamic shadows also, maybe?
  • Networking via TCP vs WebSockets: Not actually needed if there's no browser involved, but it might be easier to use uws anyway
  • Particle effects: These might benefit from Compute Shaders, though BJS can also make use of them nowadays (AFAIK)
  • Skeletal animations: Built into BJS but kind of icky to use (docs have improved though!) - simply pass bone weights to the shader?
  • Audio: How difficult is it to reproduce the old AudioTrack-based JS API in raw WebAudio (LabAudio, presumably)? Very? No idea.
  • Multithreading: This the browser can't do, but it's multithreaded itself (and the performance/complexity trade-off is questionable)

I would expect this list to grow as I discover more nasty things. Perhaps it might make sense to also gather the benefits here:

  • No more JavaScript and Electron/Browser craziness, anywhere. Good riddance, I say, to all the thousands of npm modules
  • Performance of LuaJIT seems to be higher, although it might be because the old JS code sucked (TypedArrays vs cdata?)
  • Much simplifies the overall architecture, as there's no more need for microservices just to load files via RPC calls
  • No dependency on browser engines, at least if WebViews were made optional in the runtime (in favor of WebGPU)
  • Can actually implement proper testing for more than just the backend (much easier than with electron-mocha etc.)
  • Can reuse all the code between modules and no need to store data tables as JSON (or duplicate them)
  • All of the technical debt from the four or so JS/TS versions is just gone - such a rewrite might in this case be a huge win
  • I will have to learn a lot more of the low-level details, by necessity, which I would consider a win even if I dread certain areas

Obviously, using WebGPU means reinventing many wheels.

But it might still be worth it (and I'm curious to learn more about graphics).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions