Use DWMApi to minimize queueing of composited swapchains

Use DwmAPI, if available, to minimize queueing of presents.

Fixes crbug.com/85096

Committed: http://code.google.com/p/angleproject/source/detail?r=673

[nduca, 2011-06-02 07:02:54]

This is my latest attempt at stabilizing ANGLE framerates on composited
desktops. The original FlipEX stuff removes jitter because it allowed the DWM to
use the actual Direct3D swapchain's buffers. That effectively limited the amount
of queuing that DWM could perform to 2 frames.

However, due to issues around how FlipEx works during resizing, Chromium can't
use the FlipEx effect [or anyone who doesn't paint inside WM_PAINT] without
getting nasty paint artefacts.

So, this patch dynamically loads the DWM API (dwmapi.dll) and uses
DwmSetPresentParameters [if available] to minimize the amount of queueing that
DWM can do on our swap chains. This prevents the hitching artifacts we were
seeing.

I somewhat guessed on how to expose these various function pointers. DWM's API
is straight C, and I didn't see any "preferred method" in ANGLE for doing this
sort of bulk-API loading. If there is a preferred style for this, let me know
and I'll adjust the code accordingly.

[apatrick1, 2011-06-02 18:11:34]

http://codereview.appspot.com/4559065/diff/4004/src/libEGL/Display.cpp
File src/libEGL/Display.cpp (right):

http://codereview.appspot.com/4559065/diff/4004/src/libEGL/Display.cpp#newcod...
src/libEGL/Display.cpp:226: HMODULE dwmModule =
GetModuleHandle(TEXT("dwmapi.dll"));
One way to avoid all this binding would be to specify dwmapi.dll as a /DELAYLOAD
DLL in the gyp file. That will generate stubs that automatically look up these
entry points the first time they are called. Then all that is needed is to check
GetVersion reports Vista or later before calling any of them.

http://msdn.microsoft.com/en-us/library/yx9zd12s(VS.80).aspx

http://codereview.appspot.com/4559065/diff/4004/src/libEGL/Surface.cpp
File src/libEGL/Surface.cpp (right):

http://codereview.appspot.com/4559065/diff/4004/src/libEGL/Surface.cpp#newcode87
src/libEGL/Surface.cpp:87: presentParams.fQueue = FALSE;
MSDN implies FALSE is the default and sort of implies that the other fields of
this struct need be filled only if it is TRUE. It is rather vague though. Maybe
it is because we are using D3D on the window the present parameters are being
changed?

http://msdn.microsoft.com/en-us/library/aa969501(VS.85).aspx

I'm also a little wary of doing this in ANGLE since it will affect other things
dependent on ANGLE. Since D3D is not involved here, could we just set the
present parameters in Chrome itself, potentially in the browser process when the
window is created. Or is it necessary to do this every time a swap chain is
created for the window?

[dgkoch, 2011-06-02 18:22:58]

http://codereview.appspot.com/4559065/diff/4004/src/libEGL/Display.cpp
File src/libEGL/Display.cpp (right):

http://codereview.appspot.com/4559065/diff/4004/src/libEGL/Display.cpp#newcod...
src/libEGL/Display.cpp:226: HMODULE dwmModule =
GetModuleHandle(TEXT("dwmapi.dll"));
On 2011/06/02 18:11:34, apatrick1 wrote:
> One way to avoid all this binding would be to specify dwmapi.dll as a
/DELAYLOAD
> DLL in the gyp file. That will generate stubs that automatically look up these
> entry points the first time they are called. Then all that is needed is to
check
> GetVersion reports Vista or later before calling any of them.
> 
> http://msdn.microsoft.com/en-us/library/yx9zd12s%28VS.80%29.aspx

Please make sure it's still possible to build this on WinXP using the
stand-alone projects too.

[kbr1, 2011-06-02 18:30:41]

http://codereview.appspot.com/4559065/diff/4004/src/libEGL/Surface.cpp
File src/libEGL/Surface.cpp (right):

http://codereview.appspot.com/4559065/diff/4004/src/libEGL/Surface.cpp#newcode92
src/libEGL/Surface.cpp:92: ERR("Unable to set present parameters: %081X");
Is there an argument missing at the end to match the format specifier?

[nduca, 2011-06-03 19:28:14]

Regarding the "does this belong in angle" questions...

I'm of a split mind about having this not in ANGLE. I've noticed that this same
trick is something that everyone doing windowed interactive content on Vista+
does. So, in some regards, I half think we're being nice to the library's users
by helping their performance, rather than hurting them.

But, I dont have 100% confidence in this being a clear win for every possible
use case. So, in an ideal world, I'd prefer to put this into Chrome and
eventually move it to ANGLE if/when we really 100% understand the benefit it
offers.

Unfortunately, I've spent the last day trying to get it into Chrome but with no
luck. I've tried setting this flag after surface creation and also after
resizing, but it doesn't have the same effect. There must be some subtlety in
when we need to tell DWM to lay off with the buffering and when we make an HWND
composited.

Given some of the near term pressures to stabilize frame rate and the minimal
risk of doing it that way, I'd leaning toward still putting this into ANGLE.
But, again, I'd defer to everyone else's wisdom on what actually to do. :)

[apatrick1, 2011-06-03 20:10:29]

LGTM for my part. Remember to update version.h before checking in.

[nduca, 2011-06-06 16:42:52]

Daniel, any comments? I'm pressed up against a chrome deadline, it'd be great to
sort this out today.

[dgkoch, 2011-06-06 16:48:52]

On 2011/06/06 16:42:52, nduca wrote:
> Daniel, any comments? I'm pressed up against a chrome deadline, it'd be great
to
> sort this out today.

k. looking now

[dgkoch, 2011-06-06 17:10:47]

LGTM.  

I presume this should still build on WinXP assuming you have the latest platform
SDK?

[nduca, 2011-06-06 17:49:30]

I'll double check it now.

[nduca, 2011-06-06 18:55:32]

Verified it builds on winxp [given a current platform sdk]