imgref

imgref copied to clipboard

Using SIMD instructions on windows requires allocations be aligned to 16 bytes. Vec does not align to 16 bytes when allocating.

Vec on stable does not permit fallible allocations either, which is critical when allocating large bitmaps.

Would it be possible/practical to allow something other than Vec as a container, or should this be a separate crate?

This crate will let you create Img<SomeContainer>, but it may be of limited use. You can create a temporary Img<&[T]> from any container.

I couldn't implement Img<T> where T: AsRef<[Pixel]>, since there's no place to define the pixel type (unconstrained type).

Perhaps it could be solved by defining a VecLike<T> trait to abstract over containers. I'm happy to take PRs for that.

@lilith How about fixing the issues with Vec instead? Possibly harder to pull off, but benefits everyone!

Fallible allocation for Vec has been stalled for years pending other improvements.

Aligned allocation would nearly impossible to insert into Vec ergonomically.

On Thu, Oct 22, 2020, 3:41 PM Anton Marsden [email protected] wrote:

@lilith https://github.com/lilith How about fixing the issues with Vec instead? Possibly harder to pull off, but benefits everyone!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kornelski/imgref/issues/15#issuecomment-714778299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2LH4EFK4XPSUDLDAOMRDSMCRH7ANCNFSM4S23KG5Q .

@lilith That's unfortunate. I am hoping the allocation API stabilizes eventually so we have more control of (re-)allocation, at least within custom data structures.

@lilith I have been building a 2D library (called TooDee, funnily enough) that does allow you wrap a slice and get 2D functionality - take a look at TooDeeViewMut. You'd have to create the aligned slice yourself, obviously.