Mac: move content::RenderWidgetResizeHelper to ui::WindowResizeHelperMac (acelerated_widget_mac)

content/browser/browser_main_loop.cc

Index: content/browser/browser_main_loop.cc
diff --git a/content/browser/browser_main_loop.cc b/content/browser/browser_main_loop.cc
index dbfb590ac48055aa7a05f0715b5bdd80d1f1e53a..32ec264e555f92585a763c5c0b22dec14d8a5dcc 100644
--- a/content/browser/browser_main_loop.cc
+++ b/content/browser/browser_main_loop.cc
@@ -108,6 +108,7 @@
 #include "content/browser/compositor/browser_compositor_view_mac.h"
 #include "content/browser/in_process_io_surface_manager_mac.h"
 #include "content/browser/theme_helper_mac.h"
+#include "ui/accelerated_widget_mac/window_resize_helper_mac.h"
 #endif
 
 #if defined(USE_OZONE)
@@ -701,6 +702,11 @@ int BrowserMainLoop::PreCreateThreads() {
   }
 #endif
 
+#if defined(OS_MACOSX) && !defined(OS_IOS)
+  // The WindowResizeHelper synchronizes IO thread tasks with the UI thread.

[jam, 2015/09/17 23:25:16]

can you describe this some more? are we making the UI thread wait on the IO, or
vice versa?

[tapted, 2015/09/18 00:36:55]

Updated the comment, now says

  // The WindowResizeHelper allows the UI thread to wait on specific renderer
  // and GPU messages from the IO thread. Initializing it before the IO thread
  // starts ensures the affected IO thread messages always have somewhere to go.

There's also a lot of specific details in the WindowResizeHelper class comment
in ui/accelerated_widget_mac/window_resize_helper_mac.h

+  ui::WindowResizeHelperMac::Get()->Init(base::ThreadTaskRunnerHandle::Get());
+#endif
+
   // 1) Need to initialize in-process GpuDataManager before creating threads.
   // It's unsafe to append the gpu command line switches to the global
   // CommandLine::ForCurrentProcess object after threads are created.