Prev: Running Windows XP and Windows Vista Professional in headless mode
Next: Virtual Audio Device Driver Question
From: blackborn on 19 Mar 2007 17:20
> Got the example.
> Thanks.
> I'm following up with some of the owners
> to get a good picture ot what's going on.

Ivan, thanks for help. I'll be waiting :)

--
Andrew Solodovnikov

From: blackborn on 19 Mar 2007 19:38
> The code below (between I.B.) should get you going

Ivan, thanks! I think about EngAssociateSurface for the back surface,
but from the documentation it is not clear, that i can associate more
than one surface with the device driver.
I have tried to modify code as you explained - all works now, thanks.

BTW, i have scanned another examples from ddk and netmeeting mirror
driver - everywhere EngAssociateSurface used only with primary
surface... Are you sure that this is a correct way? For example,
netmeeting calls EngCreateBitmap and than EngBitBlt without any
troubles.
And another point that without associating my sample works with all
EngXxx, except AlphaBlend. Why AlphaBlend requires an association?
>From it's description:

A bit-block transfer with alpha blending is supported between the
following surfaces:
o From one device-managed surface to another device-managed surface.
o From one GDI-managed standard format bitmap to another GDI-managed
standard format bitmap.
o From one device-managed surface to a GDI-managed surface, and vice
versa.

Really, i can't understand why it needs association... Why i cannot
blend from one DIB to another? Is there another EngXxx "draw"
functions, that require association?

Sorry for "stupid" questions - i'm just trying to understand a
background, not only visible results. Thanks!


PS from React OS sources associating is very formal:

00444 BOOL STDCALL
00445 EngAssociateSurface(IN HSURF Surface,
00446 IN HDEV Dev,
00447 IN ULONG Hooks)
00448 {
00449 SURFOBJ *SurfObj;
00450 BITMAPOBJ *BitmapObj;
00451 GDIDEVICE* Device;
00452
00453 Device = (GDIDEVICE*)Dev;
00454
00455 BitmapObj = BITMAPOBJ_LockBitmap(Surface);
00456 ASSERT(BitmapObj);
00457 SurfObj = &BitmapObj->SurfObj;
00458
00459 /* Associate the hdev */
00460 SurfObj->hdev = Dev;
00461 SurfObj->dhpdev = Device->PDev;
00462
00463 /* Hook up specified functions */
00464 BitmapObj->flHooks = Hooks;
00465
00466 BITMAPOBJ_UnlockBitmap(BitmapObj);
00467
00468 return TRUE;
00469 }

Only differences i see from the disassemble of the win32k is run-time
checks for a non-null device handle and LockBitmap return value, and
one big difference - flags in the native implementation is OR-ed... As
i understand from the crush dump - EngAlphaBlend tries to read from
the null internal PDEV (hdev member), so it expected hdev to be non-
null and did not check it at all. Is this the bug of EngAlphaBlend?

From: blackborn on 19 Mar 2007 21:06
> AlphaBlend requires to derive a palette from the destination surface,
> in order to have the mask to sample the Alpha-Channel.
> The palette is stored in the PDEV.
> Un-Associated Eng-Managed bitmap don't have a palette,
> and, those surface get the palette from the default XLATEOBJ.
> You need to close the gap by giving a PDEV to the surface,
> in order for the palette to be found.

Thanks, now i see.

First  |  Prev  | 
Pages: 1 2
Prev: Running Windows XP and Windows Vista Professional in headless mode
Next: Virtual Audio Device Driver Question