Several minor improvements of DirectX capturer

Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of reference
counted pointers (Microsoft::WRL::ComPtr), there is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

3. AcquireNextFrame returns both a DXGI_OUTDUPL_FRAME_INFO with
AccumulatedFrames and an IDXGIResource. But there is no comment in MSDN to
ensure IDXGIResource won't be nullptr if AccumulatedFrames > 0. Adding an extra
check in DxgiOutputDuplicator makes it a safer.

BUG=314516
Committed: https://crrev.com/66cadfc0e33f5368a86f2ebb52cc200a95c3ba1a
Cr-Commit-Position: refs/heads/master@{#14341}

[Hzj_jie, 2016-09-15 23:46:14]

Description was changed from

==========
Fix a crash issue in DirectX capturer on certain machines

Set D3D_DRVIER_UNKNOWN for certain machines may result strange side effects.
Since we should use hardware to accelerate the capturer, so change to
D3D_DRIVER_HARDWARE instead.

BUG=
==========

to

==========
Several minor improvements of DirectX capturer

1. Set D3D_DRVIER_UNKNOWN for certain machines may result strange side effects.
Since we should use hardware to accelerate the capturer, so change to
D3D_DRIVER_HARDWARE instead.

2. DXGI_OUTPUT_DESC returns a DPI aware screen size, we should convert it to a
DPI independent screen size. Since the data from GPU (AcquireNextFrame API) is
DPI independent.

BUG=
==========

[Hzj_jie, 2016-09-16 00:35:29]

Description was changed from

==========
Several minor improvements of DirectX capturer

1. Set D3D_DRVIER_UNKNOWN for certain machines may result strange side effects.
Since we should use hardware to accelerate the capturer, so change to
D3D_DRIVER_HARDWARE instead.

2. DXGI_OUTPUT_DESC returns a DPI aware screen size, we should convert it to a
DPI independent screen size. Since the data from GPU (AcquireNextFrame API) is
DPI independent.

BUG=
==========

to

==========
Several minor improvements of DirectX capturer

1. Set D3D_DRVIER_UNKNOWN for certain machines may result strange side effects.
Instead we will try D3D_DRIVER_TYPE_HARDWARE / D3D_DRIVER_TYPE_WARP /
D3D_DRVIER_TYPE_REFERENCE.


2. DXGI_OUTPUT_DESC returns a DPI aware screen size, we should convert it to a
DPI independent screen size. Since the data from GPU (AcquireNextFrame API) is
DPI independent.

BUG=
==========

[Hzj_jie, 2016-09-16 02:04:07]

Patchset #1 (id:1) has been deleted

[Hzj_jie, 2016-09-16 02:22:25]

Description was changed from

==========
Several minor improvements of DirectX capturer

1. Set D3D_DRVIER_UNKNOWN for certain machines may result strange side effects.
Instead we will try D3D_DRIVER_TYPE_HARDWARE / D3D_DRIVER_TYPE_WARP /
D3D_DRVIER_TYPE_REFERENCE.


2. DXGI_OUTPUT_DESC returns a DPI aware screen size, we should convert it to a
DPI independent screen size. Since the data from GPU (AcquireNextFrame API) is
DPI independent.

BUG=
==========

to

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. ComPtr released before
it should be. So a simple solution is to use copy instead of reference. The
D3dDevice is a collection of pointers, there is almost no extra cost.

2. DXGI_OUTPUT_DESC returns a DPI aware screen size, we should convert it to a
DPI independent screen size. Since the data from GPU (AcquireNextFrame API) is
DPI independent.

3. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

BUG=
==========

[Hzj_jie, 2016-09-16 02:23:20]

Patchset #1 (id:20001) has been deleted

[Hzj_jie, 2016-09-16 03:21:29]

Description was changed from

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. ComPtr released before
it should be. So a simple solution is to use copy instead of reference. The
D3dDevice is a collection of pointers, there is almost no extra cost.

2. DXGI_OUTPUT_DESC returns a DPI aware screen size, we should convert it to a
DPI independent screen size. Since the data from GPU (AcquireNextFrame API) is
DPI independent.

3. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

BUG=
==========

to

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of pointers, there
is almost no extra cost.

2. DXGI_OUTPUT_DESC returns a DPI aware screen size, we should convert it to a
DPI independent screen size. Since the data from GPU (AcquireNextFrame API) is
DPI independent.

3. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

BUG=
==========

[Hzj_jie, 2016-09-16 18:16:37]

Patchset #1 (id:40001) has been deleted

[Hzj_jie, 2016-09-16 19:22:07]

Description was changed from

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of pointers, there
is almost no extra cost.

2. DXGI_OUTPUT_DESC returns a DPI aware screen size, we should convert it to a
DPI independent screen size. Since the data from GPU (AcquireNextFrame API) is
DPI independent.

3. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

BUG=
==========

to

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of pointers, there
is almost no extra cost.

2. By default DXGI_OUTPUT_DESC returns a DPI aware screen size, we should
disable this behavior by setting SetProcessDPIAware and SetProcessDpiAwareness,
to get DPI independent screen size. Since the data from GPU (AcquireNextFrame
API) is DPI independent.

3. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

BUG=
==========

[Hzj_jie, 2016-09-16 19:25:37]

Patchset #1 (id:60001) has been deleted

[Hzj_jie, 2016-09-16 20:40:42]

zijiehe@chromium.org changed reviewers:
+ sergeyu@chromium.org

[Hzj_jie, 2016-09-16 21:37:14]

zijiehe@chromium.org changed reviewers:
- sergeyu@chromium.org

[Jamie, 2016-09-16 21:54:09]

jamiewalch@chromium.org changed reviewers:
+ jamiewalch@chromium.org

[Jamie, 2016-09-16 21:54:10]

This feels like three unrelated changes. Even for simple changes like this, it's
better to use separate CLs so that the reviewer understands the end goal for
every line of code (and so can reason about whether or not it achieves that
goal). It also minimizes collateral damage if one of the changes needs to be
reverted. Can you split it into separate CLs?

https://codereview.chromium.org/2345163002/diff/80001/webrtc/modules/desktop_...
File webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc (right):

https://codereview.chromium.org/2345163002/diff/80001/webrtc/modules/desktop_...
webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc:33:
SetProcessDpiAwareness(PROCESS_PER_MONITOR_DPI_AWARE);
According to
https://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx,
use of these functions is discouraged; we should set this in the manifest
instead. If that's not possible for some reason, then I think this should be
done explicitly somewhere early in main(), rather than as a side-effect of
creating a DxgiDuplicatorController. WDYT?

[Hzj_jie, 2016-09-16 22:27:47]

Patchset #2 (id:100001) has been deleted

[Hzj_jie, 2016-09-16 22:32:50]

Patchset #2 (id:110001) has been deleted

[Hzj_jie, 2016-09-16 22:35:59]

Description was changed from

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of pointers, there
is almost no extra cost.

2. By default DXGI_OUTPUT_DESC returns a DPI aware screen size, we should
disable this behavior by setting SetProcessDPIAware and SetProcessDpiAwareness,
to get DPI independent screen size. Since the data from GPU (AcquireNextFrame
API) is DPI independent.

3. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

BUG=
==========

to

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of pointers, there
is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

BUG=
==========

[Hzj_jie, 2016-09-16 22:37:45]

On 2016/09/16 21:54:10, Jamie wrote:
> This feels like three unrelated changes. Even for simple changes like this,
it's
> better to use separate CLs so that the reviewer understands the end goal for
> every line of code (and so can reason about whether or not it achieves that
> goal). It also minimizes collateral damage if one of the changes needs to be
> reverted. Can you split it into separate CLs?
> 
>
https://codereview.chromium.org/2345163002/diff/80001/webrtc/modules/desktop_...
> File webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc (right):
> 
>
https://codereview.chromium.org/2345163002/diff/80001/webrtc/modules/desktop_...
> webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc:33:
> SetProcessDpiAwareness(PROCESS_PER_MONITOR_DPI_AWARE);
> According to
>
https://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx,
> use of these functions is discouraged; we should set this in the manifest
> instead. If that's not possible for some reason, then I think this should be
> done explicitly somewhere early in main(), rather than as a side-effect of
> creating a DxgiDuplicatorController. WDYT?

I have removed the first issue, which is not a real issue capturer should take
care.
The other two are too trivial, you may not like a change which only removes two
&.

[Hzj_jie, 2016-09-16 22:37:53]

https://codereview.chromium.org/2345163002/diff/80001/webrtc/modules/desktop_...
File webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc (right):

https://codereview.chromium.org/2345163002/diff/80001/webrtc/modules/desktop_...
webrtc/modules/desktop_capture/win/dxgi_duplicator_controller.cc:33:
SetProcessDpiAwareness(PROCESS_PER_MONITOR_DPI_AWARE);
On 2016/09/16 21:54:10, Jamie wrote:
> According to
>
https://msdn.microsoft.com/en-us/library/windows/desktop/ms633543(v=vs.85).aspx,
> use of these functions is discouraged; we should set this in the manifest
> instead. If that's not possible for some reason, then I think this should be
> done explicitly somewhere early in main(), rather than as a side-effect of
> creating a DxgiDuplicatorController. WDYT?

I have just talked with Joe, the manifest has already embedded in our binary.
And I believe Chrome is also enabled DPI awareness, so I do not need to do it
here.
What I really need to do is to embed the same manifest in
it2me_standalone_host_main.

[Hzj_jie, 2016-09-16 22:56:44]

zijiehe@chromium.org changed reviewers:
+ sergeyu@chromium.org

[Jamie, 2016-09-17 00:49:30]

LGTM with nits.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc (right):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc:152: resource) {
Please add something to the CL description for this change.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h (right):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h:114: const D3dDevice
device_;
No need for const if it's not a reference.

Please update the CL description to specify that this is a collection of
*reference-counted* pointers.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_texture_staging.h (left):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_texture_staging.h:61: const D3dDevice&
device_;
No need for const.

[Hzj_jie, 2016-09-19 18:52:25]

Description was changed from

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of pointers, there
is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

BUG=
==========

to

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of reference
counted pointers (Microsoft::WRL::ComPtr), there is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

3. AcquireNextFrame returns both a DXGI_OUTDUPL_FRAME_INFO with
AccumulatedFrames and an IDXGIResource. But there is no comment in MSDN to
ensure IDXGIResource won't be nullptr if AccumulatedFrames > 0. Adding an extra
check in DxgiOutputDuplicator makes it a safer.

BUG=
==========

[Hzj_jie, 2016-09-19 19:09:58]

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc (right):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_output_duplicator.cc:152: resource) {
On 2016/09/17 00:49:30, Jamie wrote:
> Please add something to the CL description for this change.

Done.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h (right):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h:114: const D3dDevice
device_;
On 2016/09/17 00:49:30, Jamie wrote:
> No need for const if it's not a reference.
> 
> Please update the CL description to specify that this is a collection of
> *reference-counted* pointers.

Updated the description.
I remember we have discussed const decorator before, as in Chromium const class
fields are not so common. But I do think it's a good idea for both maintainness
and correctness.
For the maintainness, readers can simply assume these fields won't be changed
during the lifetime of the instance.
For the correctness, since the logic is somehow complex, unexpected changing to
these variables may trigger undebuggable situation, as we are using lots of
Windows APIs, and their callstacks are not always available.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_texture_staging.h (left):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_texture_staging.h:61: const D3dDevice&
device_;
On 2016/09/17 00:49:30, Jamie wrote:
> No need for const.

Same explanation in dxgi_output_duplicator.h.

[Jamie, 2016-09-19 19:16:07]

Still LGTM.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h (right):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_output_duplicator.h:114: const D3dDevice
device_;
On 2016/09/19 19:09:57, Hzj_jie wrote:
> On 2016/09/17 00:49:30, Jamie wrote:
> > No need for const if it's not a reference.
> > 
> > Please update the CL description to specify that this is a collection of
> > *reference-counted* pointers.
> 
> Updated the description.
> I remember we have discussed const decorator before, as in Chromium const
class
> fields are not so common. But I do think it's a good idea for both
maintainness
> and correctness.
> For the maintainness, readers can simply assume these fields won't be changed
> during the lifetime of the instance.
> For the correctness, since the logic is somehow complex, unexpected changing
to
> these variables may trigger undebuggable situation, as we are using lots of
> Windows APIs, and their callstacks are not always available.

Thanks for the detailed rationale. If the style guide doesn't prohibit this,
then I'm happy to keep them const.

[Sergey Ulanov, 2016-09-19 22:15:19]

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_texture_staging.cc (right):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_texture_staging.cc:65: _com_error error
= device_.d3d_device()->CreateTexture2D(
do you need _com_error here instead of HRESULT?
Same question about other places where _com_error is used to store HRESULT.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_texture_staging.cc:73: error =
_com_error(stage_.As(&surface_));
remove _com_error() from here and everywhere as well?
Note that style-guide doesn't allow c-style casts.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_texture_staging.h (right):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_texture_staging.h:61: const D3dDevice
device_;
I'm not sure you actually need this. Maybe just pass D3dDevice reference to
CopyFrom()?

[Hzj_jie, 2016-09-19 23:15:27]

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_texture_staging.cc (right):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_texture_staging.cc:65: _com_error error
= device_.d3d_device()->CreateTexture2D(
On 2016/09/19 22:15:19, Sergey Ulanov wrote:
> do you need _com_error here instead of HRESULT?
> Same question about other places where _com_error is used to store HRESULT.

What _com_error can provide is the functionality to convert a non-user-friendly
magic Windows error number into a meaningful string by calling its
ErrorMessage() function.
The ErrorMessage() has been used widely in the log output.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_texture_staging.cc:73: error =
_com_error(stage_.As(&surface_));
On 2016/09/19 22:15:19, Sergey Ulanov wrote:
> remove _com_error() from here and everywhere as well?
> Note that style-guide doesn't allow c-style casts.

Indeed this is a _com_error constructor, if using
"error = stage_.As(&surface_);",
this constructor is also involved.
I will remove all explicit constructor calls, this constructor is not declared
with explicit.

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
File webrtc/modules/desktop_capture/win/dxgi_texture_staging.h (right):

https://codereview.chromium.org/2345163002/diff/130001/webrtc/modules/desktop...
webrtc/modules/desktop_capture/win/dxgi_texture_staging.h:61: const D3dDevice
device_;
On 2016/09/19 22:15:19, Sergey Ulanov wrote:
> I'm not sure you actually need this. Maybe just pass D3dDevice reference to
> CopyFrom()?

The DxgiTextureMapping does not need to use D3dDevice at all, so the two
implementations (DxgiTextureMapping and DxgiTextureStaging) have different
constructors, but identical CopyFrom() function with the intersect of the
required parameters.

[Sergey Ulanov, 2016-09-21 20:30:45]

lgtm

[Hzj_jie, 2016-09-21 21:05:33]

The CQ bit was checked by zijiehe@chromium.org

[Hzj_jie, 2016-09-21 21:05:33]

The patchset sent to the CQ was uploaded after l-g-t-m from
jamiewalch@chromium.org
Link to the patchset: https://codereview.chromium.org/2345163002/#ps150001
(title: "Resolve review comments")

[commit-bot: I haz the power, 2016-09-21 21:05:38]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-09-21 21:10:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-21 21:10:57]

Try jobs failed on following builders:
  presubmit on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/8605)

[Hzj_jie, 2016-09-21 21:12:49]

Description was changed from

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of reference
counted pointers (Microsoft::WRL::ComPtr), there is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

3. AcquireNextFrame returns both a DXGI_OUTDUPL_FRAME_INFO with
AccumulatedFrames and an IDXGIResource. But there is no comment in MSDN to
ensure IDXGIResource won't be nullptr if AccumulatedFrames > 0. Adding an extra
check in DxgiOutputDuplicator makes it a safer.

BUG=
==========

to

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of reference
counted pointers (Microsoft::WRL::ComPtr), there is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

3. AcquireNextFrame returns both a DXGI_OUTDUPL_FRAME_INFO with
AccumulatedFrames and an IDXGIResource. But there is no comment in MSDN to
ensure IDXGIResource won't be nullptr if AccumulatedFrames > 0. Adding an extra
check in DxgiOutputDuplicator makes it a safer.

BUG=314516
==========

[Hzj_jie, 2016-09-21 21:13:18]

The CQ bit was checked by zijiehe@chromium.org

[commit-bot: I haz the power, 2016-09-21 21:13:31]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-09-21 23:06:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-21 23:06:13]

Try jobs failed on following builders:
  android_arm64_rel on master.tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[Hzj_jie, 2016-09-22 00:09:49]

The CQ bit was checked by zijiehe@chromium.org

[commit-bot: I haz the power, 2016-09-22 00:09:56]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-09-22 00:19:13]

Description was changed from

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of reference
counted pointers (Microsoft::WRL::ComPtr), there is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

3. AcquireNextFrame returns both a DXGI_OUTDUPL_FRAME_INFO with
AccumulatedFrames and an IDXGIResource. But there is no comment in MSDN to
ensure IDXGIResource won't be nullptr if AccumulatedFrames > 0. Adding an extra
check in DxgiOutputDuplicator makes it a safer.

BUG=314516
==========

to

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of reference
counted pointers (Microsoft::WRL::ComPtr), there is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

3. AcquireNextFrame returns both a DXGI_OUTDUPL_FRAME_INFO with
AccumulatedFrames and an IDXGIResource. But there is no comment in MSDN to
ensure IDXGIResource won't be nullptr if AccumulatedFrames > 0. Adding an extra
check in DxgiOutputDuplicator makes it a safer.

BUG=314516
==========

[commit-bot: I haz the power, 2016-09-22 00:19:14]

Committed patchset #3 (id:150001)

[commit-bot: I haz the power, 2016-09-22 00:19:19]

Description was changed from

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of reference
counted pointers (Microsoft::WRL::ComPtr), there is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

3. AcquireNextFrame returns both a DXGI_OUTDUPL_FRAME_INFO with
AccumulatedFrames and an IDXGIResource. But there is no comment in MSDN to
ensure IDXGIResource won't be nullptr if AccumulatedFrames > 0. Adding an extra
check in DxgiOutputDuplicator makes it a safer.

BUG=314516
==========

to

==========
Several minor improvements of DirectX capturer
1. It looks like ComPtr cannot work well with vector::emplace_back, I got a
consistent crash on one of my machine, but not the other. Move constructor
should have no impact to lvalue reference, but I may be wrong here. The
impact here is ComPtr released before it should be. So a simple solution is to
use copy instead of reference. The D3dDevice is a collection of reference
counted pointers (Microsoft::WRL::ComPtr), there is almost no extra cost.

2. Actively set several fields in D3D11_TEXTURE2D_DESC to avoid potential break
if there are some platform changes later.

3. AcquireNextFrame returns both a DXGI_OUTDUPL_FRAME_INFO with
AccumulatedFrames and an IDXGIResource. But there is no comment in MSDN to
ensure IDXGIResource won't be nullptr if AccumulatedFrames > 0. Adding an extra
check in DxgiOutputDuplicator makes it a safer.

BUG=314516

Committed: https://crrev.com/66cadfc0e33f5368a86f2ebb52cc200a95c3ba1a
Cr-Commit-Position: refs/heads/master@{#14341}
==========

[commit-bot: I haz the power, 2016-09-22 00:19:20]

Patchset 3 (id:??) landed as
https://crrev.com/66cadfc0e33f5368a86f2ebb52cc200a95c3ba1a
Cr-Commit-Position: refs/heads/master@{#14341}