3 ms·
> E.g. in Windows, when specifying color value using COLORREF they use the BGR format 0x00bbggrr. Wait a little bit... isn't Windows little-endian [1]? Followi
by cesarb 8y ago
> E.g. in Windows, when specifying color value using COLORREF they use the BGR format 0x00bbggrr.
Wait a little bit... isn't Windows little-endian [1]? Following the link in that sentence:
> typedef DWORD COLORREF;
> The low-order byte contains a value for the relative intensity of red; the second byte contains a value for green; and the third byte contains a value for blue.
Given that Windows is and has always been little-endian, the byte order of a COLORREF is red first, then green, then blue, that is, the order is RGB. So the reason for BGR can't be Windows' COLORREF.
[1] "A decision was made VERY long ago that Windows would not be ported to a big-endian processor." https://blogs.msdn.microsoft.com/larryosterman/2005/06/07/the-endian-of-windows/ https://blogs.msdn.microsoft.com/larryosterman/2005/06/07/th...
- kosma 8y agoThat's precisely how little endian works: first memory location is LSB. union { uint32_t l; uint8_t b[4]; } u = { .b = { 0x12, 0x34, 0x56, 0x78 } }; assert(u.l == 0x78563412);
- deleted 8y ago[deleted]
- mark-r 8y agoI thought for a moment that they had the order of COLORREF wrong, but I just double-checked the definitions of the GetRValue, GetGValue, and GetBValue macros. You are correct, writing that DWORD into memory would put them in RGB order not BGR.