tiny-skia VS image-png

You can even check https://github.com/linebender/piet and https://github.com/RazrFalcon/tiny-skia. They are pure rust libraries. Skia as a whole is a big binary to add.

Looking through the source code. It looks like it's using tiny-skia for rendering.

Tiny Skia (https://github.com/RazrFalcon/tiny-skia) which is a slower Rust port of Skia and does all software rendering.

https://github.com/RazrFalcon/tiny-skia is pretty great.

I understand that this may sound harsh, but I also ported two (far bigger) codebases from C++ to Rust: rustybuzz and tiny-skia. Both of which are production -ready and not just prototypes. And mine not only do not use pointers, but also barely use unsafe in general.

Here is a real world implementation in tiny-skia: https://github.com/RazrFalcon/tiny-skia/blob/master/src/pipeline/highp.rs

How about tiny-skia?

How about tiny-skia? Almost the same performance as C, no unsafe, a lot of explicit SIMD.

Now I would love to see a universal Bezier path crate, storage + common utilities like length, point at offset, some low-level stuff, etc. So it could be used as a foundation for other crates. Currently, there is a lot of friction because each crate has its own implementation.

Nice to see tiny-skia in use.

Encoding images to PNG with the "fast" compression mode is now an order of magnitude faster. This is achieved using a custom Zlib compression implementation that leverages assumptions about the patterns in PNG data to get reasonable compression ratios at phenomenal speeds.

However, the latest release of the png crate - published less than a day ago - has an ultrafast compression mode that's slightly faster than the QOI reference implementation at a comparable compression ratio. So basically you get the properties of QOI in a much more widely used image format.

In other areas, miniz_oxide is faster than miniz, Symphonia is faster than ffmpeg on most codecs, the not-yet-announced zune-png beats both libpng and the more heavily optimized libspng, and the png crate is getting considerable improvements too and also beats libpng.

gif, png, zune-jpeg are on par with their C counterparts in terms of performance

Fun fact: libpng-sys was so difficult to create safe Rust wrapper for that people just wrote their own, 100% safe Rust PNG decoder: https://github.com/image-rs/image-png

I didn't get time to finish the full spec for my attempt at a PNG decoder but it was working on common cases and was faster than image-png at the time https://users.rust-lang.org/t/new-rust-png-decoding-library/30952. I suspect it's not the case anymore since it changes it's deflate crate usage. Here is the perf issue on the image crate https://github.com/image-rs/image-png/issues/114. My code was way simpler than the one in the image crate so that might still be worth a read if you are interested.

The crate actually forbids unsafe. There's nothing necessarily wrong with unsafe code, but not having it provides a nice assurance. Plus if you are willing to tolerate (well audited) unsafe code then you may well be better off just using libpng.