Taking a little break from the wasm debugger to integrate harfbuzz into &orca

Switching between wasm and internal bytecode views, and adding breakpoints &orca

Stepping through my wasm interpreter's internal bytecode (wip wasm3 replacement for &Orca)

I wrote a blog post describing Orca's vector graphics backend: https://orca-app.dev/posts/240426/vector_graphics.html &orca

!til here's part two of my learning jam project &colors where I explain gamma correction and sRGB encoding, and update the vector graphics renderer of &orca to be gamma correct
https://youtu.be/cFoi1OLHFQ0

The tiger is back. Running pretty ok already without much optimization. I could probably cull a lot more stuff. &orca

Just added strokes (converting strokes to filled paths for now) &orca

Added MSAA in the compute shader. It might be more efficient to let a fragment shader "automatically" do it, but I'd have to change the simple final blit pass with a draw indirect call that generates triangles for each touched tile... will test later! &orca

Finally, propagating tile-local winding numbers to get global winding numbers. We can now fill paths!
Now I've got a bunch of cleanup to do. And then strokes, texturing, anti-aliasing, clipping, translucency (not necessarily in that order) &orca

Same, but merging the tile bins across paths, and rasterizing only the tiles inside the bounding box of the path control points &orca

Another building block for orca's webgpu vector graphics render: binning monotonic curves per-path and per-tile and computing tile-local winding numbers &orca

I just finished adding GLES bindings to &orca, so I figured I could try porting my old WebGL fluid sim experiments to it, and it was very pleasingly easy: https://www.youtube.com/watch?v=NqfEtRGEdYU

@bvisness wrote a small breakout game in &orca using our vector graphics renderer! Some platform discrepancies to iron out still, but it's shown here running on windows and macos.

I added a logging API and a basic in-app console in &orca, that displays log entries emitted by the guest webassembly module. It doesn't look like much yet, but it's already a nice quality of life improvement. The entries are also structured, meaning it could later be used to filter them or to jump to the line that generated the message, set a breakpoint, etc.

As a small jam experiment, I added an overlay to &orca that shows you the source code of the webassembly module it's running, and displays colored dots next to the functions that are executed. The color itself indicates the time spent in that functions during the frame relative to the other functions of the module (ie, green = less weight, red = more weight).

I implemented another method for &orca gpu vector graphics renderer. Same ghostscript tiger as before (1600x1200 window, 8x msaa), approximately 6x faster: https://twitter.com/forkingpathsdev/status/1644636281459056642?s=20 (edit: deleted and reuploaded, because I can't do twitter right and I posted the video of the previous method)

I wrote about the styling system I use in &orca UI toolkit, which solves some problems I had with stack based approaches: https://www.forkingpaths.dev/posts/23-03-10/rule_based_styling_imgui.html

Squeezed one last feature on &orca before the finish line. Launching apps from the browser, with a choice to cache them for offline use.

Not much visible progress on &orca today, but I did a lot of background work!

• I now load and run real wasm modules in the tab processes, and compile shaders and call gles from them.
• I also wrote a crappy python script to autogenerate (most of) the API binding code (some of them are more tricky to automate, because the require knowledge of the semantics of the arguments, e.g. glShaderSource, so I write binding code for them manually).
• Oh and I also designed a simple messaging protocol between my processes, and can send input events to the tabs. Then if the wasm module provides a handler for that event (i.e. defines a function like OnMouseUp() or OnFrameResize()), this gets called automatically (i.e. no need to register input handlers).

So now I can click to change the direction of rotation of my triangle. Phew! But to be fair, I warned you that there's wasn't much eye candy today!

Phew! I Finally figured out a way to do cross-process graphics. So now I can give each tab process a GLES context, that can be displayed inside the main &orca process. To celebrate I'm having some remote triangles!

Intro video to my jam entry &orca https://youtu.be/1HM-VUi2YlE

Day3 - The &orca launcher now loads metadata from the app bundles it finds in the local apps folder. You can click an icon to select an app and see its banner and description. Double clicking creates a new tab backed by a separate process.

Just a very crude UI mockup for the first day! The OS is making handling animations during resize overly painful, and I spent way too much time on this :lol_sobbing: &orca