Prev: A sort of "query remove lock"?
Next: MaximumTransferSize limit for bulk on EHCI in Vista RC2 (5744)?
From: Maxim S. Shatskih on 11 Oct 2006 19:13
> There is a system provided display driver, called cdd.dll, that is in
> charge all the times that desktop composition in NOT active.
> cdd.dll is a Punt-to-Eng display driver, and, furthermore, it performs
> synchronization with video memory with a custom interface with dxgkrnl.sys.

So, cdd.dll is an old pre-Vista video driver, which is 100% universal wrapper
(conceptually) around the WDDM drivers and is based on DDraw/D3D facilities of
the underlying hardware and the WDDM driver? is it so?

> When there is desktop composition active, then,
> there is no display driver whatsoever, and, the GDI applications are
> redirected
> to eng-managed bitmaps.

Am I correct that, with desktop composition, win32k remembers the bitmap for
each window (kinda like CS_SAVEBITS), that GetDC and BeginPaint return a DC
which references this internal bitmap (and not the screen DC with customized
CLIPOBJ and coordinate origin, as it was in pre-Vista Windows since 16-bit
3.0), and that then this bitmap is rendered to the real screen by desktop
composition engine itself? is it so?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Ivan Brugiolo [MSFT] on 11 Oct 2006 21:52
> So, cdd.dll is an old pre-Vista video driver, which is 100% universal
> wrapper
> (conceptually) around the WDDM drivers and is based on DDraw/D3D
> facilities of
> the underlying hardware and the WDDM driver? is it so?
>
Yes. The only point is that it uses a custom interface against dxgkrnl.sys
that causes dxgkrnl!DXGCONTEXT::SubmitPresent to be called.

> Am I correct that, with desktop composition, win32k remembers the bitmap
> for
> each window (kinda like CS_SAVEBITS), that GetDC and BeginPaint return a
> DC
> which references this internal bitmap (and not the screen DC with
> customized
> CLIPOBJ and coordinate origin, as it was in pre-Vista Windows since 16-bit
> 3.0), and that then this bitmap is rendered to the real screen by desktop
> composition engine itself? is it so?
>
Partially yes.
NtUser was anyway saving the bitmap for each window privided that the
window was created as layered and/or redirected. Immagine that in
compose desktop mode each window is layered by the system.

The CS_SAVEBITS flag was only used for parts of the window
(for example, you had a pop-up menu in a CS_SAVEBITS window. In this case,
NtUser was saving the bits of the window, popping-up the menu, and restoring
the bits of the window without asking the window to redraw).
CS_SAVEBITS was a temporary trick bound to the specific operation,
and, it was optional, in the sense that NtUser could choose
to always ask the window to redraw.

GetDC and /or GetWindowDC can reference the redirection bitmap
instead of the primary surface of the display driver, in redirection mode.

The final bitmap that builds up a window is presented to the screen
after it has become a IDirect3DSurface9/IDirect3dTexture9,
as part of the render pass for the screen.

--
--
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


"Maxim S. Shatskih" <maxim(a)storagecraft.com> wrote in message
news:OrbLBrY7GHA.3644(a)TK2MSFTNGP03.phx.gbl...
>> There is a system provided display driver, called cdd.dll, that is in
>> charge all the times that desktop composition in NOT active.
>> cdd.dll is a Punt-to-Eng display driver, and, furthermore, it performs
>> synchronization with video memory with a custom interface with
>> dxgkrnl.sys.
>
> So, cdd.dll is an old pre-Vista video driver, which is 100% universal
> wrapper
> (conceptually) around the WDDM drivers and is based on DDraw/D3D
> facilities of
> the underlying hardware and the WDDM driver? is it so?
>
>> When there is desktop composition active, then,
>> there is no display driver whatsoever, and, the GDI applications are
>> redirected
>> to eng-managed bitmaps.
>
> Am I correct that, with desktop composition, win32k remembers the bitmap
> for
> each window (kinda like CS_SAVEBITS), that GetDC and BeginPaint return a
> DC
> which references this internal bitmap (and not the screen DC with
> customized
> CLIPOBJ and coordinate origin, as it was in pre-Vista Windows since 16-bit
> 3.0), and that then this bitmap is rendered to the real screen by desktop
> composition engine itself? is it so?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim(a)storagecraft.com
> http://www.storagecraft.com
>


From: Maxim S. Shatskih on 11 Oct 2006 22:00
> NtUser was anyway saving the bitmap for each window privided that the
> window was created as layered and/or redirected. Immagine that in
> compose desktop mode each window is layered by the system.

Thanks for the answer. Looks like I must refresh my USER32 knowledge about
layered and redirected windows. In what OS version did they appear?

> CS_SAVEBITS was a temporary trick bound to the specific operation,
> and, it was optional, in the sense that NtUser could choose
> to always ask the window to redraw.

Oh, I see. I remember that Windows 3.0 had a SaveScreenBitmap in the video
driver to this very purpose. Was it connected with CS_SAVEBITS?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim(a)storagecraft.com
http://www.storagecraft.com

From: Ivan Brugiolo [MSFT] on 12 Oct 2006 12:28
> Looks like I must refresh my USER32 knowledge about
> layered and redirected windows. In what OS version did they appear?

Layered windows appeared in Windows 2000.

> Oh, I see. I remember that Windows 3.0 had a SaveScreenBitmap in the video
> driver to this very purpose. Was it connected with CS_SAVEBITS?

Yes, it was connected, in the sense that a CS_SAVEBITS window
could cause NtUser to ask NtGdi to ask the display driver to save the area
underneath the Pop-Up menu.

--
--
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


"Maxim S. Shatskih" <maxim(a)storagecraft.com> wrote in message
news:uGYmUIa7GHA.4568(a)TK2MSFTNGP02.phx.gbl...
>> NtUser was anyway saving the bitmap for each window privided that the
>> window was created as layered and/or redirected. Immagine that in
>> compose desktop mode each window is layered by the system.
>
> Thanks for the answer. Looks like I must refresh my USER32 knowledge about
> layered and redirected windows. In what OS version did they appear?
>
>> CS_SAVEBITS was a temporary trick bound to the specific operation,
>> and, it was optional, in the sense that NtUser could choose
>> to always ask the window to redraw.
>
> Oh, I see. I remember that Windows 3.0 had a SaveScreenBitmap in the video
> driver to this very purpose. Was it connected with CS_SAVEBITS?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim(a)storagecraft.com
> http://www.storagecraft.com
>


First  |  Prev  | 
Pages: 1 2 3
Prev: A sort of "query remove lock"?
Next: MaximumTransferSize limit for bulk on EHCI in Vista RC2 (5744)?