Hacker News Reader

Impeller renderer is about 100 KB [0]. You still need to add things like text layouting library and image codecs to that size. A few MB in total I guess, but much less than a full web engine.

While Flutter could be used to draw UI to texture, Impeller could also be used by other UI frameworks. Recently, Avalonia team experimented with replacing Skia and a Flutter developer asked, if they are interested in using Impeller and even offered some help [1].

This would probably be suitable, as a more lightweight alternative to WebView, for integrating into game engines.

[0] https://chromium.googlesource.com/external/github.com/flutte...

[1] https://www.reddit.com/r/dotnet/comments/1nv3snm/comment/nh7...

Even if you don't opt for gpu compositing, you can be 8x more performant than skia by writing something yourself. Skia is optimized for portability, not necessarily performance.

I wonder if Tauri is subject to this.

The sooner Tauri grows Electron/Chrome bundling capabilities, the better.

Chunky and predictable beats confusion, errors, and inconsistencies.

By that logic, every website should bundle their own web browser. They don't. Browsers are consistent enough, especially when you limit your web browsers to only those that OSes provide as web view components.

Bundling your dependencies is in fact something applications like to do though. The question becomes whether your browser/runtime is the layer you stop including deps or the os native apis which that browser is built on top is. When you get to physical products the OS is absolutely part of the dependencies you want to control and deploy, even if it largely exists to run a single application.

Safari and Edge scare the user about pointer lock control, which makes it annoying/impossible to build nice 3D games or visualizations in Tauri. Every on click event is met with a huge, scary browser-native alert. Chrome doesn't do that.

That's just one of dozens of browser inconsistencies we've recently dealt with. It's just the most egregious.

Safari and Edge aren't that interesting, since Tauri uses the OS's native web view, not Safari or Edge. Are you saying that the web view also scares the user about pointer lock control?

Yes. The OS's native web view uses the same rendering/JS engines as the OS's preferred browser choice. This is why native web views are inconsistent, and in this case, crippled.

By that logic, every app that utilizes Python scripting should bundle their own Python runtime.

And they do.

Python is neither backwards nor forwards compatible. The web is very stable.

And most people don't have a Python runtime installed. Almost everyone has an OS with a web view component already installed.

You don't need to bundle that much, when you have tooling to retrieve reproducible dependencies and build the whole thing in reproducible ways.

This shouldn't be a problem with Windows 11 anymore? AFAIK, the "evergreen" version of WebView2 is installed by default.

It might even be better than that. It sounds like Microsoft pushed WebView2 to (at least some) Windows 10 computers (N.B. Steam says 32% of users are still on Windows 10).

Of course, the docs still say:

> Even if your app uses the Evergreen distribution mode, we recommend that you distribute the WebView2 Runtime, to cover edge cases where the Runtime wasn't already installed.

https://learn.microsoft.com/en-us/microsoft-edge/webview2/co...

I wish we knew how prevalent that situation was. Not sure what the failure mode would be. But it sure would be nice to be able to assume that a modern WebView always exists on Windows! That certainly wasn't the case back when I made my decision circa 2022.

It was added in 22H2 Windows 10.

Out of curiosity how do you feel about wasm? Reason I am asking is I've been doing something like this but using Go and phaserjs. I've found the experience pretty awesome and my main target was the web so didn't think beyond that. My choice was based on comfort with Go and a big frustration with the react eco system (also low expertise there).

I started out really hyped for Deno, but I feel like in most cases Bun or WASM end up being better options. WASM is a great option because it has real security unlike Deno, it's a bit more involved to work with but that project setup cost gets amortized over the life of a big project, so the main downside is build chain speed, but Go is pretty good there.

Yeah build speed was actually quite good (I am sure rust-wasm has better over all performance but I am not that advanced yet). Two things I still am not able to get a feel for is:

a. load time - the Go wasm bundles can be large (TinyGo should help) but even with 25mb -> 5mb - that 5mb feels like big especially on a mobile download (i think?). But this is one off so I can suck it up.

b. This feels like a big one. I am only doing turn based games so may not be a big issue but it feels like the wasm <-> browser ser/deser can be a killer. Thank fully I am not doing high (or even medium) FPS games so will deal with that later :D

> b

I investigated wasm as a scripting engine (not a compile target, which is a orettt great use case for wasm) and the thing that killed it for me was how difficult it was to do zero-copy host-wasm memory sharing. Wasm is designed to be sandboxed and breaking those guarantees is hard. The problems I hit were: 1. Many languages (AssemblyScript, Grain) expect to own the entire linear memory, so even with WASM shared memory, it isn’t safe to actually use it unless you jump through hoops (eg use AssemblyScript GC functions to allocate and pin memory for host use), 2. WASM multi memory promises to solve this by letting you attach additional separate linear memories but neither AssemblyScript nor Grain support it. Additionally the wasmer runtime doesn’t yet support it.

I didn’t investigate whether Rust or Emscripten had either of these issues (I assume not), but they felt like a poor choice for “scripting”. I also didn’t investigate using V8 or other JavaScript engines to run wasm.

I guess the performance depends on how much you have to serialise. The ideal is to work in SharedArrayBuffers directly on linear structures of primitives and avoiding serialisation altogether. I did this for a (JavaScript) particle system where the simulation is in a web worker, that way you can achieve zero copy and it’s fast. But yeah once you have to cross the boundary and convert those or copy data, performance is hurt quite a bit…

Pardon the delay. Love this analysis. I think you were the person who's particle system post that inspired me to give wasm a deeper look (as I was saying mine is just turn based games so not exactly a demanding workload).

My thought was - can I take a language that I am comfortable with and is reasonable fast (both to develop and from perf persepective) and use that as my "logic layer". C and Rust would also have been great but for me C's memory management (Id be lying if I said I am comfortable after being away for over a decade) and battery-light standard library (again not sure what changed in last 10+ years) kept me at Go (Rust learning curve I did not even want to think about).

Back to the performance penalties - I structured it so that payloads are small and all state is kept on the wasm side with just batched messages to update view state. If I ever need to do do high FPS things il have to dig more into SharedArrayBuffers (but felt this was pain to get working). But then Id have reimplement a lot of the libs like phaserjs etc?

I don't think I posted about my particle system, so I don't think I'm the same person.

> But then Id have reimplement a lot of the libs like phaserjs etc?

The way I see it is that you either:

1. Do everything in WASM, using your languages native libraries (eg Emscripten supports SDL and WebGL, for example -- I hear newest wasm version also makes more directly available from browser WASM)

2. Use WASM to offload certain workfloads or simulation, and send data to Javascript and do all rendering in Javascript (using three.js, PIXI.js, or WebGL directly).

If using 2, you either send updates (I made a little toy test engine where I wrote messages to a SharedArrayBuffer that the JS side could read), or you operate directly on primitives in a SharedArrayBuffer (fastest since there's no serialisation needed, but harder to do).

Note for my particle system, I used PIXI.js to render and the webworker to simulate. I had a read index and a write index and the simulation would basically read the particle attributes from the read index and write them to the write index. The read index would be incremented for each particle and the write index only for live particles, meaning that as particles died it auto compacted:

    let read_index = 0
    let write_index = 0
    let numParticles = liveParticles
    const view = new DataView(sharedBuffer)
    do {
        const x = view.getFloat32(read_index + 0)
        const y = view.getFloat32(read_index + 4)
        const pos = update(x, y) // whatever your update logic actually is
        const stillAlive = // ...
        if (stillAlive) {
            view.setFloat32(write_index + 0, pos.x)
            view.setFloat32(write_index + 4, pos.y)
            // only advance for live particles
            write_index += SIZE_OF_PARTICLE_IN_BYTES
        }
        read_index += SIZE_OF_PARTICLE_IN_BYTES
    } while (--numParticles > 0)

Simplified for illustrative purposes. In real life, I used a wrapper than managed offsets automatically. But the point is that its a flat buffer, we don't try to serialise objects other than to read the properties out and write them back.

Interesting. Aere you using Ebiten for wasm?

https://ebitengine.org/en/documents/webassembly.html

Dang I am not sure why I was downvoted. But to your question I just used a basic MVP pattern where the Go side was pushed events from the browser and the game lib did the validation and called back methods on the browser to update the view state. So the browser side was very stateless for me. This made my testing a lot easier.

MicrosoftEdgeWebview2Setup.exe /silent /install

I'm assume (wrongly?) that installing this dependency is managed by Steam before the first run, not up to them.

One can opt in to the common redistributables (which usually makes sense if the thing you're looking for is covered) or decide to package custom steps into InstallScript files https://partner.steamgames.com/doc/sdk/installscripts. In either approach, Steam will automatically manage the runtime dependency installation for the user before the "Play" button appears.

Thanks for the info. Looks like they're using /silent right there in the example

"Steam customers love a quick and silent install. Add silent or quiet parameters to all run process commands and only add what you absolutely need for the game."

Is there really no way to get around the webview2 installer? Why not package it in your app bundle somehow instead of installing it as an external dependency?

> Is there really no way to get around the webview2 installer?

WebView2 supports both the auto-updating "Evergreen" version and a fixed version[1]:

In the Fixed Version distribution mode, you control the timing of updates to the WebView2 Runtime for your app. You download a specific version of the WebView2 Runtime and then package it with your WebView2 app. The WebView2 Runtime on the client isn't automatically updated.

[1]: https://learn.microsoft.com/en-us/microsoft-edge/webview2/co...

For me personally, I was trying to avoid bundling an entire browser runtime, so I viewed that approach (bundling WebView2's runtime instead of downloading on demand, only if needed) as no better than using Electron. At the time, that also wouldn't have solved my "Linux support" problem, but the blog post author is using webivew (which uses WebKitGTK on Linux), so that might not be relevant to them either. At which point I have nothing relevant to say!

I made an attempt at using WebKitGTK on Linux to build a WebGL game a couple of years ago. I was basing it on some existing code that I had already done a ton of work with to optimize and make cross-browser compatible. Had basically 99% feature parity between Chrome and Firefox.

Lack of standards support in WebKit made it painful to use and even meant losing major features like VR support. WebKit and WebKitGTK were both extremely unstable in their own ways. And I never could figure out a decent debugging scenario setup.

Hah that is so unfortunate when it’s so much nicer not to be using electron.

omg, not the electron, please! How about NW.js?