MSDN states:Dlaczego Windows GDI używa formatu RGBA zamiast "COLORREF" zamiast BGRA?
Określając wyraźnego koloru RGB wartość COLORREF ma po szesnastkowym:
0x00bbggrr
Bajt bajtu zawierającego wartość względnego natężenia czerwony; drugi bajt zawiera wartość dla koloru zielonego; a trzeci bajt zawiera wartość dla niebieskiego. Bajt wyższego rzędu musi wynosić zero. Maksymalna wartość dla jednego bajtu to 0xFF.
Od 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))
jak Windows jest little endian, COLORREF jest w formacie RGBA. To wygląda dziwnie, ponieważ nie jest to format kolorów, którego Windows używa wewnętrznie, BGR (A)?
Struktura RGBQUAD jest zdefiniowana jako
typedef struct tagRGBQUAD {
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
który jest, w przeciwieństwie do COLORREF, BGRA.
Ponieważ funkcja bitblt oczekuje tablicy o wartościach COLORREF, oznacza to, że zawsze istnieje dodatkowa konwersja z RGBA do BGRA podczas każdego połączenia, jeśli system Windows używa BGRA jako formatu natywnego.
Nie pamiętam poprawnie, ale czytałem też gdzieś, że istnieje dziwna mieszanka w formacie pikseli użytych w winapi.
Czy ktoś może wyjaśnić?
Twoje stwierdzenie jest nieprawdziwe; makra wyraźnie tworzą COLORREF w kolejności 0x00bbggrr. Spójrz na nich ponownie lub napisz jakiś kod z nich i obserwuj wynik. – Clifford
System Windows używa formatu OS/2 do plików BMP, a format OS/2 różni się na kilka sposobów od tego, co Windows wolałby inaczej. Jednym z nich jest to, co już zauważyłeś: R i B są odwrócone. Innym jest to, że bitmapy OS/2 są od dołu do góry zamiast zstępujące. –
@RaymondChen Dokładnie! Zawsze muszę wstawić '-' podczas określania wysokości bitmapy z tego powodu. Czy istnieje sposób na blit bez przechodzenia przez konwersję formatu RGB w GDI? – xiver77