Support GPU VSync when DirectComposition isn't enabled

Support GPU VSync when DirectComposition isn't enabled

This fixes a few additional issues that came up in private testing.

1) Blank screen with DirectComposition isn't enabled. What happens is
   that GPU VSync ends up being activated on Compositor side but not
   on GPU side. I'd prototyped this solution when I tested GPU VSync
   on Win 7 but decided to leave it out because I mistakenly assumed
   that DirectComposition is always available on Win 8+. I verified
   this but running Chrome with --disable-direct-composition flag.
   
2) In gpu_vsync_provider_win.cc "GpuVSyncWorker::SendVSyncUpdate"
   trace event always logs adjustment = 0 due to incorrect variable
   scope. 

3) It was pointed out to me that if D3DKMTWaitForVerticalBlankEvent
   keep returning an error for whatever reason the worker thread
   would just spin. It might be a better idea to just crash in that
   unlikely case so that we can investigate the crash dump.

What would be a condition for GL Implementation being anything other
than kGLImplementationEGLGLES2? Should we care about that case?

BUG=467617
Review-Url: https://codereview.chromium.org/2710183004
Cr-Commit-Position: refs/heads/master@{#453050}
Committed: https://chromium.googlesource.com/chromium/src/+/f188ef999b74cbf90fee37f3dd7a4cc53a701334

[stanisc, 2017-02-23 21:12:16]

The CQ bit was checked by stanisc@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-23 21:12:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-23 22:20:30]

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

[commit-bot: I haz the power, 2017-02-23 22:20:31]

Dry run: This issue passed the CQ dry run.

[stanisc, 2017-02-23 23:12:47]

Description was changed from

==========
Support GPU VSync when DirectComposition isn't enabled

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

to

==========
Support GPU VSync when DirectComposition isn't enabled

This fixes a few additional issues that came up in private testing.

1) Blank screen with DirectComposition isn't enabled. What happens is
   that GPU VSync ends up being activated on Compositor side but not
   on GPU side. I've prototyped this solution when I tested GPU VSync
   on Win 7 but decided to leave it out because I mistakenly assumed
   that DirectComposition is always available on Win 8+. I verified
   this but running Chrome with --disable-direct-composition flag.
   
2) In gpu_vsync_provider_win.cc "GpuVSyncWorker::SendVSyncUpdate"
   always logs adjustment = 0

3) It was pointed out to me that if D3DKMTWaitForVerticalBlankEvent
   keep returning an error for whatever reason the worker thread
   would just spin. It might be a better idea to just crash in that
   unlikely case so that we can investigate the crash dump.

What would be a condition for GL Implementation being anything other
than kGLImplementationEGLGLES2? Should we care about that case?

BUG=467617
==========

[stanisc, 2017-02-23 23:20:34]

Description was changed from

==========
Support GPU VSync when DirectComposition isn't enabled

This fixes a few additional issues that came up in private testing.

1) Blank screen with DirectComposition isn't enabled. What happens is
   that GPU VSync ends up being activated on Compositor side but not
   on GPU side. I've prototyped this solution when I tested GPU VSync
   on Win 7 but decided to leave it out because I mistakenly assumed
   that DirectComposition is always available on Win 8+. I verified
   this but running Chrome with --disable-direct-composition flag.
   
2) In gpu_vsync_provider_win.cc "GpuVSyncWorker::SendVSyncUpdate"
   always logs adjustment = 0

3) It was pointed out to me that if D3DKMTWaitForVerticalBlankEvent
   keep returning an error for whatever reason the worker thread
   would just spin. It might be a better idea to just crash in that
   unlikely case so that we can investigate the crash dump.

What would be a condition for GL Implementation being anything other
than kGLImplementationEGLGLES2? Should we care about that case?

BUG=467617
==========

to

==========
Support GPU VSync when DirectComposition isn't enabled

This fixes a few additional issues that came up in private testing.

1) Blank screen with DirectComposition isn't enabled. What happens is
   that GPU VSync ends up being activated on Compositor side but not
   on GPU side. I've prototyped this solution when I tested GPU VSync
   on Win 7 but decided to leave it out because I mistakenly assumed
   that DirectComposition is always available on Win 8+. I verified
   this but running Chrome with --disable-direct-composition flag.
   
2) In gpu_vsync_provider_win.cc "GpuVSyncWorker::SendVSyncUpdate"
   trace event always logs adjustment = 0 due to incorrect variable
   scope. 

3) It was pointed out to me that if D3DKMTWaitForVerticalBlankEvent
   keep returning an error for whatever reason the worker thread
   would just spin. It might be a better idea to just crash in that
   unlikely case so that we can investigate the crash dump.

What would be a condition for GL Implementation being anything other
than kGLImplementationEGLGLES2? Should we care about that case?

BUG=467617
==========

[stanisc, 2017-02-23 23:20:35]

stanisc@chromium.org changed reviewers:
+ jbauman@chromium.org

[stanisc, 2017-02-23 23:21:29]

Description was changed from

==========
Support GPU VSync when DirectComposition isn't enabled

This fixes a few additional issues that came up in private testing.

1) Blank screen with DirectComposition isn't enabled. What happens is
   that GPU VSync ends up being activated on Compositor side but not
   on GPU side. I've prototyped this solution when I tested GPU VSync
   on Win 7 but decided to leave it out because I mistakenly assumed
   that DirectComposition is always available on Win 8+. I verified
   this but running Chrome with --disable-direct-composition flag.
   
2) In gpu_vsync_provider_win.cc "GpuVSyncWorker::SendVSyncUpdate"
   trace event always logs adjustment = 0 due to incorrect variable
   scope. 

3) It was pointed out to me that if D3DKMTWaitForVerticalBlankEvent
   keep returning an error for whatever reason the worker thread
   would just spin. It might be a better idea to just crash in that
   unlikely case so that we can investigate the crash dump.

What would be a condition for GL Implementation being anything other
than kGLImplementationEGLGLES2? Should we care about that case?

BUG=467617
==========

to

==========
Support GPU VSync when DirectComposition isn't enabled

This fixes a few additional issues that came up in private testing.

1) Blank screen with DirectComposition isn't enabled. What happens is
   that GPU VSync ends up being activated on Compositor side but not
   on GPU side. I'd prototyped this solution when I tested GPU VSync
   on Win 7 but decided to leave it out because I mistakenly assumed
   that DirectComposition is always available on Win 8+. I verified
   this but running Chrome with --disable-direct-composition flag.
   
2) In gpu_vsync_provider_win.cc "GpuVSyncWorker::SendVSyncUpdate"
   trace event always logs adjustment = 0 due to incorrect variable
   scope. 

3) It was pointed out to me that if D3DKMTWaitForVerticalBlankEvent
   keep returning an error for whatever reason the worker thread
   would just spin. It might be a better idea to just crash in that
   unlikely case so that we can investigate the crash dump.

What would be a condition for GL Implementation being anything other
than kGLImplementationEGLGLES2? Should we care about that case?

BUG=467617
==========

[stanisc, 2017-02-23 23:22:44]

This is a fairly small change.
PTAL!

[jbauman, 2017-02-24 23:51:09]

lgtm.

The GL implementation will only be something different than EGL/GLES2 when using
SwiftShader. But in that case the browser should be using the software
compositor, not the gpu, so it shouldn't be driving vsync anyway. To be careful
you should check that everything works with the new feature with "--disable-gpu"
is specified on the command line"

[stanisc, 2017-02-25 01:03:19]

Verified that GPU VSync isn't used when --disable-gpu is specified.

[stanisc, 2017-02-25 01:03:32]

The CQ bit was checked by stanisc@chromium.org

[commit-bot: I haz the power, 2017-02-25 01:03:41]

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

[commit-bot: I haz the power, 2017-02-25 01:04:52]

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

[commit-bot: I haz the power, 2017-02-25 01:04:53]

Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[stanisc, 2017-02-25 01:47:14]

The CQ bit was checked by stanisc@chromium.org

[commit-bot: I haz the power, 2017-02-25 01:47:23]

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

[commit-bot: I haz the power, 2017-02-25 02:39:15]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1487987234632240, "parent_rev":
"8a9fdb7818cf338102a0c1c889d19da5f704399a", "commit_rev":
"f188ef999b74cbf90fee37f3dd7a4cc53a701334"}

[commit-bot: I haz the power, 2017-02-25 02:39:50]

Description was changed from

==========
Support GPU VSync when DirectComposition isn't enabled

This fixes a few additional issues that came up in private testing.

1) Blank screen with DirectComposition isn't enabled. What happens is
   that GPU VSync ends up being activated on Compositor side but not
   on GPU side. I'd prototyped this solution when I tested GPU VSync
   on Win 7 but decided to leave it out because I mistakenly assumed
   that DirectComposition is always available on Win 8+. I verified
   this but running Chrome with --disable-direct-composition flag.
   
2) In gpu_vsync_provider_win.cc "GpuVSyncWorker::SendVSyncUpdate"
   trace event always logs adjustment = 0 due to incorrect variable
   scope. 

3) It was pointed out to me that if D3DKMTWaitForVerticalBlankEvent
   keep returning an error for whatever reason the worker thread
   would just spin. It might be a better idea to just crash in that
   unlikely case so that we can investigate the crash dump.

What would be a condition for GL Implementation being anything other
than kGLImplementationEGLGLES2? Should we care about that case?

BUG=467617
==========

to

==========
Support GPU VSync when DirectComposition isn't enabled

This fixes a few additional issues that came up in private testing.

1) Blank screen with DirectComposition isn't enabled. What happens is
   that GPU VSync ends up being activated on Compositor side but not
   on GPU side. I'd prototyped this solution when I tested GPU VSync
   on Win 7 but decided to leave it out because I mistakenly assumed
   that DirectComposition is always available on Win 8+. I verified
   this but running Chrome with --disable-direct-composition flag.
   
2) In gpu_vsync_provider_win.cc "GpuVSyncWorker::SendVSyncUpdate"
   trace event always logs adjustment = 0 due to incorrect variable
   scope. 

3) It was pointed out to me that if D3DKMTWaitForVerticalBlankEvent
   keep returning an error for whatever reason the worker thread
   would just spin. It might be a better idea to just crash in that
   unlikely case so that we can investigate the crash dump.

What would be a condition for GL Implementation being anything other
than kGLImplementationEGLGLES2? Should we care about that case?

BUG=467617

Review-Url: https://codereview.chromium.org/2710183004
Cr-Commit-Position: refs/heads/master@{#453050}
Committed:
https://chromium.googlesource.com/chromium/src/+/f188ef999b74cbf90fee37f3dd7a...
==========

[commit-bot: I haz the power, 2017-02-25 02:39:51]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/f188ef999b74cbf90fee37f3dd7a...