Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wuffs’ PNG image decoder

nigeltao.github.io

Post reply on HN
Print view View original

121–130 of 144 posts

Re: Wuffs’ PNG image decoder

#121

Post by bschwindHN »

I recently wrote a Rust PNG decoder mostly for use in no_std contexts, and it was motivated out of wanting to decode emoji for a font rasterizer.

I didn't really put any effort into optimizing it yet, though it does use miniz_oxide and it decompresses the entire image at once instead of per-scanline.

I'm curious if it is at all competitive with the Wuffs decoder, I'm guessing probably not because I haven't put any effort into using SIMD.

https://github.com/bschwind/png-decoder

But overall the implementation was pretty straightforward, I just read the RFC and wrote it out over a few weeks. One quirk of my library currently is it always returns an RGBA buffer, instead of potentially letting you save memory on a grayscale or RGB image.

Re: Wuffs’ PNG image decoder

#122

Post by Karliss »

rurban wrote: post #60

Looks good, but has somewhat widely false claims: > SMHasher is a test and benchmark suite for a variety of hash function implementations. It can provide data for claims like “our new Foo hash function is faster than the widely used Bar, Baz and Qux hash functions”. However, when comparing Foo to CRC-32, be aware that a SIMD-accelerated CRC-32 implementation can be 47x faster than SMHasher’s simple CRC-32 implementat…

That number doesn't seem realistic. Even for future generations of ram and PCIe the bandwidth is on the order of 50GB/s not 2TB/s .

Re: Wuffs’ PNG image decoder

#123

Post by junon »

Wuffs sounds really cool, surprised I haven't heard about it. It claims memory safety but I'd be interested in how it has proven this - is it verified?

Sad that it's a Google project, but I can look past every now and again.

Re: Wuffs’ PNG image decoder

#124

Post by mckirk »

Gaelan wrote: post #113
Jweb_Guru wrote: post #104

Earlier quoted context omitted.

That is true, but on the other hand, Wuffles allows safe unchecked array indexing, which is a very hard problem that Rust doesn't attempt to tackle--in part because it spends most of its complexity budget on the borrow checker! I for one would be extremely interested in using Wuffles in the inner loop of many routines I currently write in Rust which are performance critical, and for which I know bounds checking is hu…

> I would particularly love it as an embedded language, rather than one needing a full-blown application. Given the existence of [0], I imagine this is doable. [0]: https://docs.rs/inline-python/0.6.0/inline_python/

That inline Python is the closest thing to black magic I've seen in a while. I guess I have to find an excuse to play around with Rust some time soon, it seems like such a cool ecosystem.

Re: Wuffs’ PNG image decoder

#125

Post by nigeltao »

rurban wrote: post #114

What does `choosy_up` stand for? Looks like choosy stands for vtable, and up for parent, right?

Sorry, that part is relatively new and poorly documented.

Choosy is sort of vtable-ish. It selects between method implementations (which all have the same signature), typically based on cpuid (e.g. if the CPU is SSE4.2+PCLMUL capable, set foo = foo_x86_sse42; if not, use the default foo impl).

up (the private method) just implements update (the public method). Only private methods can be choosy.

Re: Wuffs’ PNG image decoder

#127

Post by pjmlp »

dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

You should have a look at Frama-C (https://frama-c.com/) as well for this kind of stuff.

Re: Wuffs’ PNG image decoder

#128

Post by pjmlp »

mleonhard wrote: post #61
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

MISRA-C(++), Ada/SPARK also forbid it, yet they are there powering lots of embedded systems, there is a lot of stuff that can still be implemented with such restrictions.

Re: Wuffs’ PNG image decoder

#129

Post by pjmlp »

amenghra wrote: post #82
mleonhard wrote: post #61

Earlier quoted context omitted.

Wuffs touts its lack of memory allocation as a safety feature [0]. Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect. I think this would be a good idea. Wuffs types are not parameterized with lifetimes, so they may contain references only to items with static lifetime. This means that Wuffs cannot implement linked lists, hash tables, or other common data structures. To support those structu…

Go & Java don't do reference counting. They have a GC instead.

Wrong, reference counting is a GC algorithm, and both language specifications don't state what exact algorithm is to be implemented.

In fact there are tons of GC implementations across all Java implementations, including reference counting.

For example, "An on-the-fly reference-counting garbage collector for java"

https://dl.acm.org/doi/10.1145/1111596.1111597

And here is one for Go.

https://github.com/sendilkumarn/gopurerc

Re: Wuffs’ PNG image decoder

#130

Post by pjmlp »

quotemstr wrote: post #38
dividuum wrote: post #2

Interesting. First time I've head of Wuffs. As someone that still uses C, this in particular sounds neat: (from https://github.com/google/wuffs#goals-and-non-goals ) """ Wuffs' goal is to produce software libraries that are as safe as Go or Rust, roughly speaking, but as fast as C, and that can be used anywhere C libraries are used. [...] Wuffs the Library is available as transpiled C code. Other C/C++ projects can u…

All of Windows (including the NT kernel) is written using the same basic proof model that Wuffs uses, except that the constraints are specified as annotations on top of C and C++ instead of as a new programming language. I prefer the annotation approach, TBH, but I'm glad to see people working on safety. Specifically, Wuffs (like Rust) has this problem where it tries to fill the same niche as C and C++ and improve on…

As info for others, here are the annotations,

https://docs.microsoft.com/en-us/cpp/code-quality/using-sal-...

Post reply on HN