Correctly parse colours on big endian systems #721
Conversation
|
@microsoft-github-policy-service agree |
| #[derive(Default, Clone, Copy, PartialEq, Eq)] | ||
| #[repr(transparent)] | ||
| pub struct StraightRgba(u32); | ||
| pub struct StraightRgba([u8; 4]); |
There was a problem hiding this comment.
I'm a bit sceptic of the performance implications here. The previous structure was essentially a u32 (including u32 alignment), which meant that "memsets" of these got nicely optimized. Compilers often have a hard time to intelligently translate equivalent lower-aligned types like this back into higher aligned ones.
I'd either like to see this investigated/benchmarked, or we could consider changing the existing methods to be endian-specific. E.g. to special-case the red/green/blue/to_bytes methods. I don't mind the change to returning u8 btw. That usually gets optimized away quite nicely anyway.
Thanks for testing this btw!
There was a problem hiding this comment.
I'm not a rust developer (mainly typescript and other interpreted languages), so I'll defer any suggestions to anyone else that can help.
If anyone does have a better solution, I'm more than happy to try and run it on a real PowerPC machine (albeit slowly at 600MHz)
2 participants
Hello world!
When running edit on my Apple iMac G3, the colours are all weird due to it being a big-endian system
This pull request ensures that colours are parsed correctly on any system by storing the RGBA components as separate
u8sThe unit test should also work in
miri- the existingoklab::tests::test_blendingshould fail without this PR.Yes this does mean one of you will may need to install Linux on a real PowerPC machine to test this PR 😸