Why GDI managed bitmaps are GBR instead of BGR or RGB?

Hi,

I've developed a mirror driver and I am punting calls to GDI with a bitmap
frame buffer.
When I look at the frame buffer the screen image is there but the pixels are
stored as GBR.
How can I solve this problem?

Sincerely,

Omer Boyaci

 

No, they aren't.

If your bitmap is a 24-bit DIB, the bytes will be B G R B G R. If your
bitmap is a 32-bit DIB, the bytes will be B G R 0 B G R 0.

 

Why are they BGR and not RGB? And why doesn't ulPrimaryOrder in the GDIINFO
seem to affect this (at least in printer drivers)?

ScottR

 

Yes, they have to be BGR but what I am talking is reality.
I opened the frame buffer and read the first three bytes then I check
these values with paint it is GBR.

When I opened a .bmp file and read the first three bytes after header
(for topdown) it is BGR you are right. But mirror driver frame buffer it
is GBR and I am creating this bitmap with these calls.

hbitmap =
EngCreateBitmap(sizel,ppdev->lDeltaScreen,BMF_24BPP,BMF_TOPDOWN,ppdev->pOpaqueSurface);
EngAssociateSurface((HSURF)hbitmap, ppdev->hdevEng, 0);
mirrsurf->surfobj = EngLockSurface((HSURF)hbitmap);

ppdev->hsurfEng = (HSURF) hsurf;
ppdev->pvTmpBuffer = (PVOID) dhsurf;

Sincerely,

Omer

 

Thank you very much Scott.
Your suggestion indeed solved my problem.

Sincerely,

Omer

 

How did you read the values from the frame buffer, and how did you verify
it?

 

My frame buffer is mapped to a file. I can read the values directly from
this file. With a small c program I am printing the first the bytes to
the console then I am taking a screenshot and opening the screenshot in
paint. I am looking the 0,0 color. They are same but the order is GBR.

Anyway, I solved the problem. Here is the solution:
I've added

pDevInfo->hpalDefault = EngCreatePalette(PAL_RGB,0, NULL, 0, 0, 0);

line to the DrvEnablePDEV.

Sincerely,

Omer