Closed CryZe closed 3 years ago
I was expecting this patch =)
And yes, as you've already figured out, the main reason why tiny-skia requires std is because I didn't had time to work on libm and stuff.
On the other hand, tiny-skia is pretty much x86-only library. So no_std is kinda pointless. Can you clarify your use case?
Does it not work properly on other architectures? I generally want to make my library compile on as many targets as possible, so no_std support for the rendering would be great. There is no super specific use case other than reducing the barrier to getting it to compile if you wanted to use my library on some weird architecture (I've compiled it to GameCube, GBA, N64 and co. before).
Should be. I haven't tested it myself. But performance is non-existent. There is no point in using tiny-skia without SIMD. And only x86-one is implemented (std::arch::arm/aarch64 is still unstable).
On the other hand, there are not much choice. It's either tiny-skia or raqote.
I don't mind this change, I just don't see much point in it. I even thought about removing non-x86 support completely, but changed my mind. If it works for you - I'm fine with it.
In my use case only a tiny portion of the image needs to be redrawn each frame, so I think it should still be fast enough. But yeah it kind of sucks a bit that ARM SIMD is still unstable, but that at least won't be the case forever (and there's also WASM SIMD in the pipeline), so I don't think it should be limited to just x86.
Actually, I don't know the real performance hit from non-SIMD build, because rustc uses SSE2 by default and you cannot disable it afaik. Overall, it should be fine.
This brings
no_std
support to tiny-skia. Various floating point functions are not available if you don't target std. For those there is a new optionallibm
feature that can be used to bring in thelibm
crate's implementations for those functions.