On Tuesday 29 July 2008 12:21:23 you wrote:
No, you shouldn't be accessing the surface per byte either, the access should depend on the format, i.e. for a 32-bit format you want to access DWORD by DWORD.
1) As I understand, surface data should be stored in same way on both big/little endian platforms, so for rgb8 blue compes first, then goes green, then red, no matter which endianness. I think so because when windows program access surface data it, data is supposed to be in same format, no matter how program accesses it - by reading bytes, dwords and words. In this way accessing r5g6b5 as dword/word on big-endian machine, will require byte-swapping, otherwise middle channel will be split in two parts. I do not have access to big-endian platform, so I can't check if that is true, and how exactly surface data is stored on big-endian platform.
2) Pixel formats have different sizes - 1..4 bytes. Reading 1-byte or 3-byte data as dwords doesn't look right.
3) And I agree that this completely defeats purpose of the function.
4) There will be ifdefs anyway. Especially if assumption in #1 is true, then each value will require byte-swapping, at least.
This won't work and I've already thought about accessing data as DWORDs, it doesn't look reasonable.
My suggestion is to accept patch as it is, until someone with access to big-endian machine will change it to be more elegant (although I don't see any way to do this).