-
Notifications
You must be signed in to change notification settings - Fork 44
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
Endianness Considerations #109
Comments
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After a long discussion in #104 (comment), we came to the conclusion that we should consider endianness when appropriate, this is mainly examples, tests and documentation.
Especially this line:
softbuffer/src/lib.rs
Line 340 in fcda747
is actually just wrong. This worked so far because literals in Rust are written in big-endian, so if you write it as 0RGB, it will come out as BGR0, because most systems are little-endian, but BGR0 is actually the correct layout.
I would like to mention that I'm strongly in favor of changing the current buffer from
[u32]
to[u8]
, which seems like a much more user-friendly API to me and also makes most of the endianness considerations go away.The main concern @ids1024 had about this is performance, which could be addressed by leaving the buffer as a
[u32]
, but expose it as[u8]
in theDeref
implementation, we could still introduce aas_u32()
method then. Though I would like to see a benchmark showing an actual performance regression before we put effort into something unconfirmed like this.The text was updated successfully, but these errors were encountered: