If an application makes a BitBlt() call to write to an area on a window which is currently completely hidden by another window, does that call get passed to DrvBitBlt()?
I would like to generate my own live custom preview (on Win 7), but I don’t think generating the preview using only the graphical information from DrvBItBlt() is sufficient because calls writing to hidden regions are filtered out.
From within a display device driver, how do I get graphical information for hidden regions?
If an application makes a BitBlt() call to write to an area on a window which is currently completely hidden by another window, does that call get passed to DrvBitBlt()?
No. That’s called “trivial rejection”, and GDI does a certain amount of
it before calling the driver.
I would like to generate my own live custom preview (on Win 7), but I don’t think generating the preview using only the graphical information from DrvBItBlt() is sufficient because calls writing to hidden regions are filtered out.
Custom preview of what?
From within a display device driver, how do I get graphical information for hidden regions?
For XPDM drivers, it’s impossible. The pixels simply do not exist.
When a window comes to the top, the application is sent a WM_PAINT
message that tells it to redraw itself. The only pixels in memory are
the pixels you see.
For WDDM drivers, this is all handled by the Desktop Window Manager.
Application windows are actually draw into offscreen surfaces, which DWM
then uses as 3D textures in order to create the composite desktop. And
because of Aero, hidden surfaces are not really hidden – they show
partly through.
However, I don’t believe there’s any way for a WDDM driver to identify
which texture belongs to which application. That’s all part of DWM.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.