WM_PAINT changes in Windows Vista

[B.Y.]

Hi everyone,

I have applications that draw complex graphics on screen. I coded some
double-buffering to minimize flashing: at WM_PAINT time, I draw my graphics
into an offscreen HDC/bitmap, and then BitBlt it to the screen HDC.

The Vista Compatibility Cookbook says the following about WM_PAINT:

Prior to Windows Vista, an hwnd was painted directly to the screen, which
had certain benefits but really limited how Windows could display and manage
top-level windows. In Windows Vista, all top-level windows are rendered to
an off-screen bitmap (similar to WS_EX_LAYERED), and the Desktop Window
Manager combines the images together to draw the desktop.

From the paragraph above, it seems there's no need to do my own double
buffering any more on Vista, since the system already does it. Is this
correct ?

Other related questions:

*How does it affect DirectDraw APIs ?
*How can I find out how frequent the DWM updates the screen ?
*Can I force a window or part of a window to be updated to screen ? For
example, if I want to refresh my window at 30Hz, but DWM only updates at 20
Hz.

Any explanation will be greatly appreciated.

[Ivan Brugiolo [MSFT]]

-1- WM_PAINT & double-buffering
The system does double buffering for you, but, there is no good way
to synchronize the drawing with a render-pass.
The render pass is triggered by the the v-blank of your screen, plus some
other selected synchronization point.
The redirection bitmap of a top-level window is treated as dirty
at the end of each GDI operation that releases the Dev-Lock.
If you manage to draw everything between two render-passes,
then, there is no need to double buffer.
If not, you might have visual tearing, even if not
as bad as if you were drawing to the screen.
[The system does not know in general when an application
had finished drawing, because there's too many application drawing
in the HDC obtained via GetDCEx() outside of the BeginPaint/EndPaint].

-2- DirectDraw.
Depending on the situation, desktop composition may turn-off if certain
DirectDraw applications are running, or, it may get the DirectDraw surface
as if it were a redirected DirectX windowed device.
As usual, implicit synchronization between DirectDraw and GDI drawing
in the same surface is not guaranteed.

-3- Frequency of the updates.
It's a complicated matter. The basic idea is to present at each vblank.
DxgKrnl.sys keeps the history of Presents
submitted to the video-mem scheduler. DWM queries that present history,
and attempts to optimize the presents submitted by the applications
(think about games of video-playback applications) and its own Present,
in order to not let video to lag behind.

-4- How to update a window.
Every time you draw to a window Device Context, the redirection bitmap
if flagged as dirty, and, the node in the visual tree is marked to be
picked-up
by the next composition pass. You cannot force a composition pass to happen
(excluding some screen-wide read-modify-write operation that is implemented
for back-compat, but, even that is going to wait for the vblank)

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

"B.Y." <by...@hotmail.com> wrote in message
news:4cLJh.82005$Du6.51891@edtnps82...