It's quite easy to get the CPU back-end running with WASM. GPU might work as well with Chrome Canary, but I haven't tested it yet. Using WebGPU should make this just as easy.
A pixel segment is a line segment that fits inside of a pixel's square box. It can start and end anywhere inside of this 1x1 square box and it has a 64bit compact representation.
forma is geared towards vector-graphics heavy use cases. A very good example would be Lottie or Rive animations or games that make use of vector graphics. Another possible use case would be places where you need a very small software renderer, like an OS's early boot.
I've added a clarification. The point of the benchmark is not to compete with other projects, it's merely there to put the parsing speed (and not necessarily the processing that comes after it) in a representative window of performance.
I agree with your point. I tried my best not to sway too far off of some of syntax I've seen in other PEG projects, while also keeping it compatible with Rust's standard macros. While pest does have this constraint any longer with the new beta, changing the grammar too much would have been a nuisance for anyone who had grammars written in the older versions.
A good place to start would be in the manually written example. [1] My current plan is to try and limit the the use of memoization such that it still guarantees linear parsing, but it doesn't memoize unless necessary.
For now, it produces a recursive descent parser. Packrat parsing is an open-question since I'm afraid that adding a memoization layer all throughout the parser will lead to a consistent general slowdown.
And, yes, it does support multi-stage parsing. After the tokens are generated, there is a process! macro which handles them. This is where you can produce an AST.
The organization's webpage is not working and there are no visible people in the organization. It's probably better to keep mrusty on anima-engine for a while. By the way, I plan to use mrusty to add an mruby API and scripting to Anima.