Skip to content
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

Pixel to Struct of Arrays (and back again!) #305

Closed
6 tasks done
Ogeon opened this issue Jan 28, 2023 · 2 comments · Fixed by #320
Closed
6 tasks done

Pixel to Struct of Arrays (and back again!) #305

Ogeon opened this issue Jan 28, 2023 · 2 comments · Fixed by #320

Comments

@Ogeon
Copy link
Owner

Ogeon commented Jan 28, 2023

Description

As discussed in #303, it would be useful to have an interface for converting an array/Vec of colors to and from Struct of Arrays format. The first step should be:

  • Construction of Rgb<S, Vec<T>> from some I: IntoIterator<Item = Rgb<S, T>>, and the same for the other color types.
  • Make it possible to get a color at some index. For example fn get_mut(&mut self, index: usize) -> Option<Rgb<S, &mut T>>.
  • Make it possible to iterate over the colors. For example fn iter_mut(&mut self) -> impl Iterator<Item = Rgb<S, &mut T>.
  • Make it simple to read from and assign to colors with reference components, such as Rgb<S, &mut T>.
  • Add counterparts to Vec::clear and Vec::extend.
  • Make it possible to push and pop individual colors.

In addition to that, we may want to add chunks and windows iterators.

The reference components will likely be necessary, due to the split into separate arrays, unless there's a smarter solution. They don't have to enable much more than reading and writing, though. It's also what would make it hard to implement the Index and IndexMut traits, if possible at all.

Motivation

The discussions in #303 covers it pretty well. One of the main reasons for a built-in interface is that it gives a way to correctly preserve the color type information across conversions. It also lowers the bar for working with SoA data.

@okaneco
Copy link
Contributor

okaneco commented Jan 29, 2023

Good summary 🙂

Another feature that I think would be useful is some way to reuse the existing allocations. It might be an extend-like interface so that users could call clear on the existing data and re-initialize with an iterator.

@Ogeon
Copy link
Owner Author

Ogeon commented Jan 29, 2023

Ah, yes, that should also be there! I'll edit the description to include them...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants