Re: How does GDI use the "hdev" element in a SURFOBJ?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

SURFOBJ::hdev should point to an internal NtGdi structure,
that is the place where the function pointers to the DrvXXX are stored.
[Caveat: in multimon and/or mirror drivers and/or watchdog cases,
there might be other layers].

SURFOBJ::dphdev should point to whatever was returend by
DrvEnablePDEV (in case of STYPE_DEVICE and STYPE_DEVBITMAP
surfaces), or to NULL, for Eng-managed bitmaps.

SURFOBJ::iType should be what is documented in MSDN.

For Eng-managed bitmap, this code should be suffcient

if (NULL == pSo->dphdev && STYPE_BITMAP == pSo->iType){
// is Eng-Manager
}

It's not clear from the description below in which circumstances
you get the null SURFOBJ::hdev, and you exactly you are creating
and associating STYPE_DEVBITMAP (Off-Screen surfaces).
My guess would be that you are trying to disguise a STYPE_BITMAP
as a STYPE_DEVBITMAP, without using an extra level of indirection
(normally implemented by storing a context pointer in SURFOBJ::dhsurf).

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Jim Haggerty" <BigIrish@xxxxxxxxxxxxxxxx> wrote in message
news:75A33EF9-373C-46F8-936B-600AA18E72CE@xxxxxxxxxxxxxxxx
I'm hoping a GDI expert can give me some clues about what the GDI is doing
when it calls our display driver. (I'm running on WinXP right now, but the
same thing happens on 2K as well.)
When GDI calls rendering functions like DrvBitBlt, and passes in source
and
destination SURFOBJs, I know I can examine various SURFOBJ fields (like
iType, dhpdev, and dhsurf) to detect the difference between GDI-managed
DIBs
and device-managed bitmaps (ie., screen surfaces or surfaces created with
DrvCreateDeviceBitmap).
But I've noticed that DIBs sometimes come in with hdev equal to zero, and
other times it's non-zero (and equal to the hdev value that I specify with
EngAssociateSurface when I create the screen surface.)
Can anyone tell me why the difference? Why does GDI consider some DIBs to
be
associated with the physical device and others not? These are all DIBs I'm
talking about - GDI-managed surfaces, and not any device-managed ones like
the screen surface.
Thanks for any light anyone can shed.

--
Jim Haggerty



.