Re: Display driver drawing corruption
- From: "Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 29 May 2008 07:20:22 -0700
1)
Depending on driver capabilities, there might be concurrent access
to the DrvXXX drawing functions. Those capabilities are not used
by any disaply driver known to be on the market, but, there used
to be a DrvSynchronize based model to allow deferred rendering
on a GPU-based worker thread, for example.
To rule concurrency out, I would do a `!locks` in KD, to ensure
that the DevLock and other mode-changed related locks are all held.
It might happen that cursor rendering operations are concurrent with
regard of other windowing operations, but, they would be still
synchronized by the DevLock. The DevLock shall not be confused with
the NuUser lock, even be sometimes both can be held at the same time
for certain HDC based operations.
2)
EngAlphaBlend is capable of `sniffing` the fact that a primary
surface is NOT device managed, and it can perform a sequence
of DrvCopyBits/EngElphaBlend/DrvCopyBits outside the
apparent knowledge of the display driver.
There used to be an display driver for a hardware being
sold in the 1999/2002 years that suffered of the same problem,
and the root cause was the primary surface being flagged
as STYPE_BITMAP.
If you look for posts of mine in the past, I think this problem
came out before, and, I recall I provided some diagnostic
tips and some workarounds.
That said, your methodology of getting the screen content
can be called `display driver filtering` that is not by any mean
a supported method to accomplish what you are tring to do.
--
--
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
"ghalpert" <ghalpert@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:D90C6273-A9DD-46E2-B201-EB8CE484C42D@xxxxxxxxxxxxxxxx
We've developed a display driver whose purpose is to capture all GDI drawing
operations, rasterize them and send them to a remote device with a display.
For various reasons we decided not to implement a mirror driver, but instead
a framebuffer display driver (using system memory) where we use the Eng* APIs
to draw on the primary surface. We hook all drawing operations on the primary
surface and specify no graphics capabilities in DEVINFO other than
GCAPS2_ALPHACURSOR. For each drawing operation we compute the framebuffer
pixels that have been modified using the dest rect of the operation and/or
the bounding rectangle of the CLIPOBJ and send those to the remote device
asynchronously from user mode.
Occassionally we experience drawing corruption, particularly with the folder
icons in Windows Explorer where a white opaque area gets drawn over the
middle of some of the icons. When the corruption happens if I press a special
key which I've programmed to perform a full screen update of the remote
display using the current contents of the framebuffer then the display
updates correctly.
From reviewing the code and observing the problem it feels like the
framebuffer is sometimes being updated asynchronously, so:
1) Are the Eng* (e.g. EngBitBlt) drawing operations on the primary surface
synchronous (i.e. will all updates to the framebuffer associated with the
surface be completed prior to the Eng* API returning) regardless of how
display acceleration is configured in Control Panel?
2) Can the graphics engine draw to the primary surface without calling our
Display Driver?
Thx,
George
.
- Prev by Date: Re: DHPDEV, PPDEV, and HDEV structure
- Next by Date: Re: file filter driver
- Previous by thread: Re: How to obtain base address?
- Next by thread: Re: Display driver install hangs in an RDP session
- Index(es):
Relevant Pages
|
