Jonathan Behrens

To clarify, the last step should probably be _deprecated_ from image crate. We'll remove all the depreciated items in one batch when we do the 0.26 release in 6-12 months...

This PR strikes me as kind of messy. It adds state tracking at the level of `ReadDecoder` which is redundant with what `StreamingDecoder` already knows. And it uses that state...

Thanks for looking into this! If you figure out a fix, please do open a PR!

Yeah, I think that's a reasonable summary. And then #458 extends this further to eliminate the idat_stream Vec

I should add that this code is fully functional. I abandoned the PR because I was burnt out dealing with complaints from entitled users, and it felt like a headache...

> And all of them have been backed by in-memory buffers, so in theory it should be possible to wrap all of them in BufRead, although some currently don't expose/require...

I have been wondering whether we should make `StreamingDecoder` private in the 0.18 release so we can try out alternatives to the byte-at-a-time decoding strategy. The hard part is figuring...

> I'm not a fan of APIs that write to `&mut [u8]`: > > * If I'm reading the whole frame into memory, I usually just want pixels in `Vec`....

Sure go ahead and add anforowicz. However, I've already [stated my stance on continued involvement with oss-fuzz](https://github.com/google/oss-fuzz/pull/12253#issuecomment-2264811341), so after this comment I'm going to fully mute any future pings.

I would like to eventually make this API change, but for now I wonder if it would be simpler to make `next_frame` call `self.next_pass()` and `self.next_interlaced_row_impl()` directly. The scratch buffer...