Re: Display driver drawing corruption

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Tim Roberts <timr@xxxxxxxxx>
Date: Sun, 17 Aug 2008 21:35:48 -0700

ghalpert <ghalpert@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

We have various requirements that make a standard mirror driver unworkable
if that would be the supported method to accomplish what we're trying to do.

It seems to me that one way to prevent this direct access to our framebuffer
by GDI would be to use an opaque device-managed surface, but how could we
punt to GDI in that case?

If you punt an operation a device-managed surface, GDI will call
DrvCopyBits to fetch the chunk of frame buffer it needs, it will dance on
the bits in memory, then it will use DrvCopyBits to put them back.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
.

References:
- Re: Display driver drawing corruption
  - From: ghalpert

Prev by Date: Re: Copy data from video memory to system memory
Next by Date: Re: How to get Full Image path in NotifyRoutine
Previous by thread: Re: Display driver drawing corruption
Next by thread: driver signing on Vista x64
Index(es):
- Date
- Thread

Relevant Pages

RE: DrvCopyBits not called from MS Paint
... "If a driver supports a device-managed surface or bitmap, ... implement the DrvCopyBits function. ... It does not mean that GDI will call DrvCopyBits always. ...
(microsoft.public.development.device.drivers)
Printer driver GDI punting problem
... I want to hook the GDI DrvXxx graphics calls (DrvBitBlt, ... and a device-managed surface so that I can hook the ... // create device-managed surface so that we can hook the DrvXxx drawing ...
(microsoft.public.development.device.drivers)