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.
I'm interested enough to click on a demo, but I'm not _quite_ interested enough to figure out what hoops I would need to jump through to get that demo running myself.
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.
That's a different kind of thing, I think. It renders using tiny-skia, so probably comparing to tiny-skia would be more appropriate? It also sounds like resvg's renderer can be swapped out, so it may be possible to have it render with Forma.
I just tried it in my own renderer (that uses tiny-skia) to compare performance, but unfortunately forma is still lacking some features to do a proper comparison (strokes, the ability to scale shapes up instead of only down (?????), rendering without clearing).
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.
about a decade ago I wanted to get started prototyping gameplay with vector graphics and I was dismayed at the state of available libraries to do this efficiently. I'm glad things seem to be getting much better in this space!
How about 3D modeling programs, like FreeCAD? That's currently single threaded and doesn't use hardware acceleration so it could use the boost for sure.
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.
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.
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.
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.
