Rust SDL2 - RGBA 数组的 PixelFormatEnum 值正确吗？

Question

我正在尝试使用 Rust 中的 sdl2 板条箱，在 CPU 上逐像素创建图像，然后将该图像绘制到窗口。
我已经弄清楚如何做到这一切，除了一个小细节：在创建我的

PixelFormatEnum

时选择正确的

Surface

。

我有一个函数可以将图像生成为

Vec<u8>

，无论字节顺序如何，它都会按

R, G, B, A, R, G, B, A, ...

的顺序生成字节，因为它单独生成字节，而不是整个像素。
然后我创建一个

Surface

，并将这些字节复制到其中。
我的问题是，在这种情况下哪个

PixelFormatEnum

是正确的？

有 4 名候选人：

PixelFormatEnum::RGBA8888

、

PixelFormatEnum::ABGR8888

、

PixelFormatEnum::RGBA32

和

PixelFormatEnum::ABGR32

。

RGBA8888

和

ABGR8888

是该枚举的实际变体，而

RGBA32

和

ABGR32

是前两者的别名，它们根据

cfg(target_endian)

更改它们别名的变体。

由于我想正确绘制图像，而不管字节顺序如何，看起来我应该选择其中一个

8888

变体，但我不确定这实际上是否正确，因为对

32

定义的评论别名为“

// Endianness-agnostic aliases for 32-bit formats

”。
这似乎表明，也许

32

别名是不会根据字节顺序改变行为的实际别名？我很困惑...

在我的小端 Windows 系统上，

ABGR8888

和

RGBA32

都可以正常工作，而另外两个则相反地解释颜色通道。不幸的是我没有大端系统，所以我无法通过测试找到答案。

Answer 1

是的，你想要

PixelFormatEnum::RGBA8888

当您想直接使用像

PixelFormatEnum::RGBA32

 这样类型的帧缓冲区并且不想担心字节顺序时，

[u32; X]

非常有用。

（

PixelFormatEnum::RGBA32

与大端系统上的

PixelFormatEnum::RGBA8888

相同，与小端系统上的

PixelFormatEnum::ABGR8888

相同。）