Don't peek messages in the MessagePumpForUI class when we receive our kMsgHaveWork message.

Currently the MessagePumpForUI class peeks Windows messages when we receive the kMsgHaveWork message in
our main message loop and in nested modal loops. This is because the posted message starves the message loop
of input and other lower priority messages. While this is ok for the main message loop our peeking and dispatching
messages in nested loops is wrong and violates the silent contract where in the nested loop should be the one peeking
and dispatching messages.

To fix this the approach we are taking is to create a worker thread which uses a waitable timer of 3 ms which posts
the kMsgHaveWork message to the main loop when the timer fires. As a result we can safely delete all the code
in the MessagePumpForUI::ScheduleWork function and simplify the ProcessPumpReplacementMessage function.

The MessagePumpForUI::ScheduleWork function now checks the delay for the task at the head of the queue
If it is 0 then we post the message right away as it is a regular task. Added functions (GetNewlyAddedTaskDelay) to the MessagePump::Delegate class and the IncomingTaskQueue for this.

The other change here is to change the GPU process to use the IO message pump by default and use the UI pump only
if we are using opengl. Reason being this patch causes a delay in processing tasks due to the worker thread which
causes tests like webgl_conformance to fail. We will continue working on addressing this over the coming days.

BUG=492837
R=cpu

Review URL: https://codereview.chromium.org/1156503005

Cr-Commit-Position: refs/heads/master@{#333572}

1 files changed, 14 insertions, 1 deletions

diff --git a/content/gpu/gpu_main.cc b/content/gpu/gpu_main.cc
index c6a59fc..71e493b 100644
--- a/content/gpu/gpu_main.cc
+++ b/content/gpu/gpu_main.cc
@@ -160,9 +160,22 @@ int GpuMain(const MainFunctionParams& parameters) {
   bool dead_on_arrival = false;
 
 #if defined(OS_WIN)
+  base::MessageLoop::Type loop_type = base::MessageLoop::TYPE_IO;
   // Use a UI message loop because ANGLE and the desktop GL platform can
   // create child windows to render to.
-  base::MessageLoop main_message_loop(base::MessageLoop::TYPE_UI);
+  // TODO(ananta) : Recent changes to the UI message pump class on Windows
+  // will cause delays in tasks getting processed in the GPU process which
+  // will show up on the bots in webgl conformance tests, perf tests etc.
+  // It will be great if we can work around the issues with desktop GL and
+  // avoid creating a child window in the GPU process which requires a UI
+  // message pump.
+  if ((command_line.HasSwitch(switches::kUseGL) &&
+       command_line.GetSwitchValueASCII(switches::kUseGL) == "desktop") ||
+      (command_line.HasSwitch(switches::kUseANGLE) &&
+       command_line.GetSwitchValueASCII(switches::kUseANGLE) == "gl")) {
+    loop_type = base::MessageLoop::TYPE_UI;
+  }
+  base::MessageLoop main_message_loop(loop_type);
 #elif defined(OS_LINUX) && defined(USE_X11)
   // We need a UI loop so that we can grab the Expose events. See GLSurfaceGLX
   // and https://crbug.com/326995.