Al especificar un color RGB explícito, el valor COLORREF tiene la siguiente forma hexadecimal:
0x00bbggrr
El byte de orden inferior contiene un valor para la intensidad relativa del rojo; el segundo byte contiene un valor para verde; y el tercer byte contiene un valor para azul. El byte de orden superior debe ser cero. El valor máximo para un solo byte es 0xFF.
Desde wingdi.h
#define RGB(r,g,b) ((COLORREF)((BYTE)(r) | ((BYTE)(g) << 8) | ((BYTE)(b) << 16))) #define GetRValue(rgb) ((BYTE) (rgb) ) #define GetGValue(rgb) ((BYTE) ((rgb) >> 8)) #define GetBValue(rgb) ((BYTE) ((rgb) >> 16)) Como Windows es Little Endian, COLORREF está en formato RGBA. Esto parece extraño porque el formato de color que usa Windows internamente, ¿no es BGR(A)?
La estructura RGBQUAD se define como
typedef struct tagRGBQUAD { BYTE rgbBlue; BYTE rgbGreen; BYTE rgbRed; BYTE rgbReserved; } RGBQUAD; que es, a diferencia de COLORREF , BGRA.
Dado que la función bitblt espera una matriz de valores COLORREF , esto significa que siempre hay una conversión adicional de RGBA a BGRA durante cada llamada, si Windows usa BGRA como su formato nativo.
No recuerdo correctamente, pero también leí en alguna parte que hay una mezcla extraña en el formato de píxeles que se usa en winapi.
¿Puede alguien por favor explicar?
Los COLORREF se remontan a cuando había mucha menos estandarización en los formatos de píxeles. Muchos adaptadores de gráficos todavía usaban paletas en lugar de colores completos de 24 o 32 bits, por lo que incluso si su adaptador requería un reordenamiento de bytes, no necesitaba hacer muchos de ellos. Algunos adaptadores de gráficos incluso almacenaron imágenes en planos de color separados en lugar de un solo plano de colores multicanal. No había una respuesta "correcta" en ese entonces.
Los RGBQUAD provienen del formato BMP, que, como mencionó Raymond Chen en los comentarios, proviene del formato de mapa de bits OS/2.