FW: Help with DrvCopyBits

NTDEV
1

Hello All,

I need some help with my implementation of a display driver.

I get DrvCopyBits call with following parameters:

Source bitmap: format BMF_8BPP (iBitmapFormat is 3) type STYPE_BITMAP
(iType = 0).

Destination bitmap: format BMF_32BPP (iBitmapFormat is 6) type
STYPE_DEVICE (iType = 1).

XLATEOBJ: XO_TRIVIAL (flXlate is 1).

The problem is that I am unable to convert 8bpp to 32bpp using trivial
XLATEOBJ (actually flag XO_TRIVIAL means that no translation needed).
And the result is wrong color display of the bitmap on the screen.

Has any one had some experince with this issue in DrvCopyBits?

Thank you for your help.

************************************************ display driver
printouts ***********************************************

qxldd: DrvCopyBits: src: iUniq 2367 sizlBitmap.cx 33 sizlBitmap.cy 38
iBitmapFormat 3 iType 0 fjBitmap 0 pos.x 0 pos.y 0

…

qxldd: DrvCopyBits: dest: iUniq 2367 sizlBitmap.cx 1024 sizlBitmap.cy
768 iBitmapFormat 6 iType 1 fjBitmap 32 dest.top 540 dest.left 254
dest.bottom 578 dest.right 287

qxldd: DrvCopyBits: XLATEOBJ: iUniq 1 flXlate 0x1 cEntries 256 pulXlate
0xbf9a39ec

qxldd: DrvCopyBits: pulXlate[0] = 0x0

qxldd: DrvCopyBits: pulXlate[1] = 0x1

qxldd: DrvCopyBits: pulXlate[2] = 0x2

qxldd: DrvCopyBits: pulXlate[3] = 0x3

qxldd: DrvCopyBits: pulXlate[4] = 0x4

.

.

.

Best regards,
Yan Vugenfirer
Qumranet.
Email: xxxxx@qumranet.com
Phone: 972-9-8858485 (138)
Mobile: 972-54-4758084
Skype: sm_yan

2

Yan Vugenfirer wrote:

I need some help with my implementation of a display driver.

I get DrvCopyBits call with following parameters:

Source bitmap: format BMF_8BPP (iBitmapFormat is 3) type STYPE_BITMAP
(iType = 0).

Destination bitmap: format BMF_32BPP (iBitmapFormat is 6) type
STYPE_DEVICE (iType = 1).

XLATEOBJ: XO_TRIVIAL (flXlate is 1).

The problem is that I am unable to convert 8bpp to 32bpp using trivial
XLATEOBJ (actually flag XO_TRIVIAL means that no translation needed).
And the result is wrong color display of the bitmap on the screen.

It means no index-to-index translation is necessary, but you still have
to go fetch the palette for the source bitmap to know what colors to
use. Are you calling XLATEOBJ_cGetPalette?

This is one of the cases where the right thing to do is punt and let GDI
do it. If your hardware can’t accelerate a function, then you should
always let GDI handle it. The GDI simulations have been heavily tuned
over the last 18 years, and it is extremely unlikely that you will be
able to do better.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Thank you for the answer.

But actually in this case our driver punts the call back to GDI and the result is bitmap in blue tones instead of the actual colors of the bitmap.

Best regards,
Yan Vugenfirer
Qumranet.
Email: xxxxx@qumranet.com
Phone: 972-9-8858485 (138)
Mobile: 972-54-4758084
Skype: sm_yan
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: ? 12 ??? 2007 20:02
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] FW: Help with DrvCopyBits

Yan Vugenfirer wrote:

I need some help with my implementation of a display driver.

I get DrvCopyBits call with following parameters:

Source bitmap: format BMF_8BPP (iBitmapFormat is 3) type STYPE_BITMAP
(iType = 0).

Destination bitmap: format BMF_32BPP (iBitmapFormat is 6) type
STYPE_DEVICE (iType = 1).

XLATEOBJ: XO_TRIVIAL (flXlate is 1).

The problem is that I am unable to convert 8bpp to 32bpp using trivial
XLATEOBJ (actually flag XO_TRIVIAL means that no translation needed).
And the result is wrong color display of the bitmap on the screen.

It means no index-to-index translation is necessary, but you still have
to go fetch the palette for the source bitmap to know what colors to
use. Are you calling XLATEOBJ_cGetPalette?

This is one of the cases where the right thing to do is punt and let GDI
do it. If your hardware can’t accelerate a function, then you should
always let GDI handle it. The GDI simulations have been heavily tuned
over the last 18 years, and it is extremely unlikely that you will be
able to do better.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer