New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unnecessary reallocation for JPEG decoding #2184
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@djc This is currently necessary due to an API mismatch between Tagging @etemesi254 because I believe they are currently working on changing how zune-image handles stream reading |
Hi, I changed it to allow it to take anything that implements a different trait, we do have stream decoding now, but because of Rust's lack of specialization, I can't blanket it to allow a it to decode It's currently specialized on some common types such as Buffered files, std io cursor and in memory buffers, wrapped with (a This is a breaking change tho, but it makes it easy to add a separate impl that allows struct ZBufReadSeeker<T:BufRead + Seek>{
source: T
}
impl<T:BufRead + Seek> ZByteReaderTrait for ZBufReadSeeker<T>{
} |
@etemesi254 great to hear this is being addressed -- I think your solution makes sense. So I guess this is just a matter of waiting for these improvements to be released? |
The |
Hi, hope I didn't keep you waiting for long, made a 0.5.0-rc0 release that should contain a fix for this. The library can now read from anything that implements |
Created #2198 to try out the new release |
When we have an in-memory JPEG image (in a
Vec<u8>
or something else that implementsAsRef<[u8]>
) and we callimage::load_from_memory()
, the image crate usesReader::make_decoder()
to create aJpegDecoder
which will then immediately create aVec<u8>
, read from theBufRead
it uses internally to represent the image data and pass a reference to theVec::as_slice()
to thezune_jpeg::JpegDecoder
. This of course allocates a full copy of the image in memory, incrementally (sinceread_to_end()
does not seem to pass a size hint).Expected
For in-memory images, the
JpegDecoder
should not copy all of the image data to a new allocation. To the extent that it does have to allocate, it should take reasonable steps up front to determine the required capacity.Actual behaviour
JpegDecoder
will incrementally allocate for a full copy of the in-memory image data.The text was updated successfully, but these errors were encountered: