Add `par_enumerate_rows(_mut)` to `ImageBuffer` and friends about image HOT 6 OPEN

So I guess the weird thing here is that you want to iterate over the rows of the image in parallel, and then for each row iterate over the pixels sequentially. We already have support if you want to do both sequentially (enumerate_rows_mut().map(|row| ...)) or both in parallel (par_enumerate_pixels_mut).

I guess I don't see an issue with adding a par_enumerate_rows{_mut} that would let you enumerate the pixels sequentially. Though it makes me wonder if all the rows iteration methods should really have Item = &[P] / Item = &mut [P] rather than in producing iterators themselves, so that the user had the option of iterating or just doing random accesses

from image.

If this were implemented with the types in this crate I would map each row to an EnumeratePixels(Mut) instead of a normal slice iterator.

from image.

I think I personally would prefer that API as it would allow, as you say, the user to call either iter or par_iter on the slices, which gives more options for how to iterate over the data.

I think changing the sequential versions of the row iterators would be a breaking change though right?

from image.

It would even let you call chunks or windows or other fancy methods on it. But yeah, it would be a breaking change for the sequential row iterations and sightly awkward to have inconsistent behavior if we didn't match for the parallel iterations

from image.

I think it is a good idea to have them be consistent, since then you can just add a par_ in front and magically have parallelism. But it also sounds like it would be a very good idea to change the row iterators to return slices in the next major version.
These two things together mean that either the parallel versions should be implemented to be consistent now and then change both them and the serial ones in the next major version, or don't implement them until the next major version where the serial ones are changed.

from image.

I would love this right now! The specific use case I have for it is maintaining per-core cache coherency and allowing SIMD to be used more easily.

from image.