April Update

Hello!

We’ve been flying under the radars for the past three months and just landed a couple big changes. Here’s what’s new in Orca.

New tooling

Our tooling was the main obstacle for early testers, as was confirmed by the feedback we got from the Handmade Network Wheel Reinvention Jam. Users were required to build the Orca runtime from source, which depended on ANGLE, and then build a lib C shim along with their application before bundling it. All of that was orchestrated by Python scripts and we soon discovered the hundred incompatible ways Python installations can differ from one machine to another. This is all gone in the new version, thanks to Ben and Shaw’s hard work.

The new user-facing tooling consists of a native command-line program that is built in CI and bundled with the necessary libraries and header files. You can download it from our latest Github release. Once you have downloaded and extracted the archive corresponding to your OS, you can put the orca folder where you want on your machine and add it to your PATH. You can then use the orca command line tool from anywhere.

The first step to build an Orca application is to produce a WebAssembly module using the Orca API. In order to do so you need to link your program to the orca library, and use our wasm-compatible C standard library. You can get the paths to these libraries by running orca sdk-path. For example, the command to build our example apps is the following:

ORCA_DIR=$(orca sdk-path)

wasmFlags=(--target=wasm32 \
  -g -O2 \
  -I "$ORCA_DIR"/src \
  -I "$ORCA_DIR"/src/ext \
  --sysroot "$ORCA_DIR"/orca-libc \
  -L "$ORCA_DIR"/bin \
  -Wl,--no-entry \
  -Wl,--export-dynamic \
  -mbulk-memory)

clang "${wasmFlags[@]}" -lorca_wasm -o module.wasm src/main.c

The second step is bundling the WebAssembly module with the Orca runtime and your app’s resources, using the orca bundle command:

orca bundle --name YourAppName --icon icon.png --resource-dir YourData module.wasm

Avoiding the need to build Orca from source and getting rid of Python also trims the list of requirements quite a bit, as you now only need a compatible installation of Clang. To learn more about how to build Orca applications, please refer to our Readme and our QuickStart guide.

Our hope is that this new tooling will considerably streamline the experience of Orca users. As a word of warning though, I should say Orca as a whole is still in an early phase of development, so you should still expect some rough spots. If you do choose to try Orca at this stage though, we’re eager to answer questions and we’d be really happy to hear your feedback about the user tooling!

New C standard library

Reuben has contributed an almost full wasm standard C library, which is no small feat! I say “almost full” only because it doesn’t includes things that don’t make sense in the context of Orca or WebAssembly, such as locales, signals, and long jumps, but it basically contains everything else. It replaces our previous lib C shim and makes it easier to reuse existing C code that relies on C standard library functions.

New WebGPU vector graphics backend

The vector graphics renderer powering Orca’s canvas API was implemented by a Metal backend on macOS, and an OpenGL backend on Windows. OpenGL implementations proved to be very inconsistent across different OS versions and GPU vendors, which caused elusive bugs and performance issues. Furthermore having to maintain different backends was a huge time drain and it could only get worse when adding new platforms.

We first considered writing a D3D backend to avoid the OpenGL issues on Windows, but I finally opted for porting the renderer to WebGPU. All things considered, this has been relatively smooth and I was pleasantly surprised by the API and the shading language. This is now our backend on both platforms, which should allow for quicker development of new features and improvements, and a more consistent experience across different OSes.

I also seized the opportunity of the Handmade Network Learning Jam to add some support for rectangular gradients, linear and sRGB color spaces, and to make the renderer gamma-correct. I made a couple videos on the subject here.

What’s next

Here’s a sneak peak into what we’ll focus on during the coming months.

Bytebox integration

Reuben is working on his own WebAssembly interpreter called Bytebox. He already added an abstraction layer to Orca that allows using Bytebox as an alternative wasm backend. Ultimately our goal is to phase out our use of wasm3 in favour of Bytebox, which will give us more freedom to explore custom WebAssembly features, and make it easier to provide a good debugging experience.

Currently Bytebox is slower than wasm3, but it is making good progress and already has better support for some more recent proposals. In the meantime we can already start experimenting with it, which is pretty exciting.

Virtual memory

One topic we want to start exploring is a 64-bit virtual memory model for Orca. The current 32 bit linear memory model is frankly one of the sore points of WebAssembly. There has been a number of proposals for 64 bit memories, multiple memories, mappable memories, etc, but none that I find satisfying in the context of Orca (and none that has gotten sufficient traction yet, for that matter).

My hunch is that there won’t be a one-size-fits-all proposal that’s also good, because different applications of WebAssembly have different and incompatible requirements and constraints. In my opinion, the details of a WebAssembly virtual memory model should be mostly deferred to target-defined specifications. A target here can encompass a number of platforms, eg. “Browsers”, or “WASI”, but shouldn’t try to encompass everything that exists or could exist. Portability should only be a concern inside a target, not accross targets.

This could be a bit of an uphill battle because it is not in the nature of specification comittees to desist from specifying things, but I don’t see how the alternative could lead to anything else than a subpar solution for everyone. In any case, we should start exploring our own design space and come up with something that’s good for Orca. I lay down some thoughts and open the discussion in this Github issue.

Debugging

Debugging is another painpoint of WebAssembly, especially for non-web platforms. This is mostly due to the fact that WebAssembly is pretty recent, because WebAssembly actually offers an easier substrate for debugging than native machine code. In Orca, the fact that we control both the virtual machine, the inputs/outputs and all the platform APIs opens a lot of avenues for interactive graphical debugging features. This also ties into the memory model, since the use of virtual memory could allow efficient snapshotting / rewinding of the wasm memory to support hot reloading and time-travel debugging.

Language bindings

Although theoretically you can use any language/toolchain capable of producing a WebAssembly module and linking to our C APIs to build an Orca app, C is currently the only officially supported language. We definitely want to address that and make it possible to write Orca apps in a wide variety of programming languages.

There has been interest in the Odin and Zig communities to make language bindings for Orca, which makes me especially excited. We should encourage and support these efforts!

We can’t necessarily write bindings ourselves, but we can make life easier for language bindings maintainers, by providing API specification files from which they can generate most of the bindings code. This way it will be easier to keep up with API changes as Orca evolves. It will also give prospective language bindings maintainers a clear view of the API surface to bind in the first place.

Conclusion

That’s all for now! I hope you enjoyed this post and as always we would love to hear your thoughts or answer your questions about Orca in the Handmade Network Discord server.

Finally as a reminder, my work on Orca is made possible by generous sponsors through Github Sponsors or Donorbox. If you’re excited by the vision of Orca and want to help make it happen, your support can make a big difference. By chipping in, monthly or as a one-time donation, you’ll allow me to dedicate more time to do research, design, programming, communication, organize the work of contributors, and ultimately lead Orca towards its goals, all without going broke and starving! This is big!

Until next time, take care~