#![no_std] support?

[tarcieri]

I'd love to use (a subset of) this library on an embedded target (Adafruit PyGamer w\ 120MHz SAMD51). These platforms have limited flash and therefore using vector graphics would permit incorporating a lot more artwork than is possible by using sprites.

Would you accept PRs to add a limited amount of no_std functionality? Any thoughts on how amenable the existing codebase would be to that sort of thing, particularly in terms of replacing existing use of heap-allocated data structures with something like heapless or handling heap allocations via the alloc crate?

[jrmuizel]

Yeah, I'm somewhat open to this provided the impact on the code base is not too bad. Currently there's quite a bit of Vec usage in a bunch of places. Depending on how things turn out it might even make sense to just have a no_std fork.

[jrmuizel]

Also, if you have any questions about how things work, I'm glad to give guidance. The real meat of raqote is in https://github.com/jrmuizel/raqote/blob/master/src/rasterizer.rs. I'd recommend looking at making that work first. It uses the arena crate and Vec. Once you have rasterizer.rs working, you can layer other stuff on top as needed.

[RazrFalcon]

Also, all the dependencies should also be no_std, which is problematic.

And also, no_std doesn't include a lot of math functions, especially for float numbers. And they are used quite a lot in the lyon.

[tarcieri]

If there’s a lot of Vec use, no_std + alloc might be good for a first pass

[tarcieri]

Re: math functionality, there are a couple options:

• The libm crate
• I wrote a math library which uses fast, small code size bitwise approximations for various f32 arithmetic operations called micromath