flo_draw VS contrast_renderer

I've been working a 2D rendering toolkit that increasingly looks to me like it probably deserves a mention on these lists: https://github.com/logicalshift/flo_draw (but I'm not on Reddit...). Layers, vector sprites, dynamic textures and a streaming API that fits well with 'reactive' designs are amongst the features that make it stand out from what else is out there. It's super simple to get going too.

Started life as a rendering layer for FlowBetween so I could put in whatever looked like it was 'winning' later on but wound up writing my own renderer as there wasn't anything quite there yet. Still has that design so another unique thing is that it's possible to use the same API with whatever rendering layer you want.

Speaking of FlowBetween, one thing I have wanted to do for ages is to get rid of the platform-specific GUIs and use something universal. It should be easy because FlowBetween sends straightforward instructions to an independent GUI layer, but I keep bouncing off for a few reasons:

- it's a big ole task so I definitely want to pick something that's stable and also lets me hedge my bets in terms of being easy to migrate away from

If Rust's your language, I wrote a library that should be pretty good at 2D things: https://github.com/logicalshift/flo_draw - I wrote it while working on another project (FlowBetween) where I found debugging would be easier if I could just render something on-screen but rendering stuff on screen always required a ridiculous amount of setup.

It has some nice options for feeding its own output back into itself as it uses streams rather than callbacks so it's quite good for procedural rendering type tasks (the 'Wibble' example is a good place to start with that)

I've been working on one for a while now that's very slowly coming together: https://github.com/logicalshift/flowbetween if you're interested.

I've been building out some backend stuff lately so there's a bunch of new features waiting to go in. https://github.com/Logicalshift/flo_draw has some demonstrations of the sort of procedural animation features I'm planning on adding, for instance.

This is true, but there is a lot more to the story. For one, WebGPU does not (yet) support mesh shaders, though it may later as an extension. For two, consider a glyph such as "o" that has two contours. Real triangulation generates a mesh that only generates triangles between the outer and inner contours, and mesh shaders aren't good at that. There are techniques (cover and stencil) that draw twice, incrementing and decrementing a winding number stored in the stencil buffer (see contrast renderer[1] for a clean modern implementation), but it does require nontrivial tracking on the CPU side, and can result in lots of draw calls to switch between the cover and stencil stages unless sophisticated batching is done.

Compute shaders avoid all these problems and work on WebGPU 1.0 today.

[1]: https://github.com/Lichtso/contrast_renderer

Thanks!

You can also checkout the "feature/ui" branch in GIT [1] to get the UI framework prototype.

[1]: https://github.com/Lichtso/contrast_renderer/tree/feature/ui