Endianness Considerations
Opened this issue · 0 comments
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:
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 the Deref
implementation, we could still introduce a as_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.