image
image copied to clipboard
make progress callback mutable
see #1488
note: this will break any downstream implementations of ImageDecoder::read_image_with_progress and ImageDecoderRect::read_rect_with_progress. However, it most cases, it should be easy to fix, just by making the callback parameter mutable. Only where the progress callback is captured or sent in multiple places, more changes might be required.
which branch should it go?
The only case where this is less general is when F is recursive, right? We never required Send or Sync so it's not possible to call the callback from a parallel decoder in the current state anyways.
Fixing the formatting...
Well, not sure if that was the right button. My brain assumed it was the Approve for Run for reasons of placement… It seems like it wasn't completely wrong though :joy:
Is there a particular rush to expose this feature? It feels like a lot of churn to add read_image_with_progress_mut in 0.24.x, deprecate it in 0.25.x, and remove in 0.26.x. So if it is possible to work around this for now (which I think it might be using Rc<RefCell> ?), I'd prefer to do that and just change the type signature of read_image_with_progress for 0.25.x.
No, we could also note this down for the next major release
I've create a new branch next-version-0.25 for all breaking changes. Feel free to amend everything into the breaking change then.
todo:
- just change the type signature of read_image_with_progress for 0.25.x instead of adding a backwards-compatible variant
@fintelia is the current stance to remove progress completely?
That's the plan at the moment, yes.
It turns out that having a method taking a callback function prevents the ImageDecoder trait from being object safe, which is a goal for the 0.25.x release. This however leaves open the possibility of adding an additional non-object safe trait for incremental decoding (like how we also have ImageDecoderRect), which we'd be able to do in a backwards compatible way
Maybe removing it now allows someone in the future to add it back in without breaking object safety. Let's remove it for now.
Or perhaps the byte-level adapter for the input stream would be a good way to do it in the future, maybe completely separate from this crate.