Jonathan Behrens

This might be better to defer until after we've gotten 0.18.0 out. It has a few consequences that are a bit hard to think through: it allocates space for entire...

This PR changes the decoder from **pulling** fixed size 32KB chunks of input data to having the caller **push** arbitrary sized chunks of data into the decoder. The default for...

Sorry, I should have been more clear. The performance regression I found only happens with this PR but _not_ on the main branch. That was what concerned me. Running a...

Any chance your CPU has a 64KB L1 cache? The current approach does three copies with size=32KB: input -> BufReader -> out_buffer -> data_stream, which should stay inside the L1...

Seeking back to the first frame makes sense to me, but I'd be curious what use seeking to a different frame would be? I'd expect that you wouldn't be able...

In order to handle additional metadata after the image data, I think we'd have to change the decoder design to initially scan through all the chunks in the file like...

Yeah, I think this should be fixed once we do a 0.18 release. There's a trickier question of how this could be exposed from the `image` crate, but that's probably...

The `BufReader` we use now serves two purposes: (a) it prevents many small reads directly hitting the underlying reader, and (b) it handles throttling the amount of data processed at...

Yeah, if you look closely at the provided methods on `BufRead`, you'll notice that they're basically a roundup of everything you might want to do if you had a 1-byte...

> If the user has a slice, then `BufRead`+`Seek` becomes just a high-overhead bug-prone interface for it. With `Seek` you now have `Cursor` indirection, and `read_exact` that generates code bloat...