You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is useful for skipping a potentially large copy when e.g. uploading texture data to a GPU, by decoding directly into a driver-allocated staging buffer or mapped memory. It would make sense for higher-level, more magical owned-memory decoders to be defined in terms of such a primitive. Compare the png crate's next_frame method.
The text was updated successfully, but these errors were encountered:
I've looked at io::Write before, but it won't work with the current implementation which writes things out of order (e.g. needs to re-read its own data to set checksums). Also the library can reserve memory it needs, but io::Write to a Vec would need to keep resizing the buffer.
However, decoding to a pre-allocated buffer makes sense and should be easy to imeplement.
it won't work with the current implementation which writes things out of order (e.g. needs to re-read its own data to set checksums).
If computing these checksums on the fly is too onerous, io::Write + io::Seek could be used. An in-memory convenience function could still query the total required storage and reserve space in a Vec (or on the filesystem, or ...).
Decoding's the case I'm actually affected by, though.
This is useful for skipping a potentially large copy when e.g. uploading texture data to a GPU, by decoding directly into a driver-allocated staging buffer or mapped memory. It would make sense for higher-level, more magical owned-memory decoders to be defined in terms of such a primitive. Compare the png crate's next_frame method.
The text was updated successfully, but these errors were encountered: