WIP - Gutterless resize on Windows

content/browser/renderer_host/render_widget_host_impl.cc

Index: content/browser/renderer_host/render_widget_host_impl.cc
diff --git a/content/browser/renderer_host/render_widget_host_impl.cc b/content/browser/renderer_host/render_widget_host_impl.cc
index 051a7bcf9f3bd67fbdcaa7b1a3da8462f1f9638b..b7af359d4c3e837bc0e00760b425cf119b8c2e40 100644
--- a/content/browser/renderer_host/render_widget_host_impl.cc
+++ b/content/browser/renderer_host/render_widget_host_impl.cc
@@ -78,7 +78,7 @@
 #endif
 
 #if defined(OS_MACOSX)
-#include "ui/accelerated_widget_mac/window_resize_helper_mac.h"
+#include "ui/base/window_resize_helper.h"

[ericrk, 2015/12/10 23:08:43]

The logic here doesn't seem to be necessary on Windows. Still trying to figure
out why the render_widget_host_impl as well as the actual bridged_native_widget
need to both have 50ms waits on mac. On windows these both cancel eachother out
(waiting in one place removes the need to wait in the other) - however, putting
the wait here introduced significant stuttering on windows.

[piman, 2015/12/11 07:53:12]

Well, if you want the UI *and* the renderer to stick to the edge, after a resize
you need to:
- resize the UI elements, including the container for the renderer (which will
send the resize to the renderer)
- wait for a frame from the renderer at the new size (WaitForSurface here)
- draw a UI frame with that renderer frame
- wait for the swap (the one in bridged_native_widget)

all of these without new resizes being serviced (i.e. blocking the message
loop).


The code here is to handle the renderer parts, on Mac, which is a little
different than Aura - the ui::Compositor only renders the renderer parts, not
the whole UI, and is resized by the renderer's frame, instead of the UI.
The 2 timeouts are meant to be nested within each other, so it could be why it
appears that they're redundant (but they may not be in all cases, e.g.
considering a slow renderer vs a slow GPU).

For Aura, the renderer parts would need to interact with the resize_lock logic
in DelegatedFrameHost/RenderWidgetHostViewAura (which was originally created for
Chrome OS, by throttling resizes rather than blocking the thread, because we
could. This code was disabled on linux/windows - see
RenderWidgetHostViewAura::DelegatedFrameCanCreateResizeLock).

[ericrk, 2015/12/15 00:25:03]

Thanks - I think it's best to save this for a follow-up? We can discuss when
you're back.

 #endif
 
 using base::Time;
@@ -900,7 +900,7 @@ void RenderWidgetHostImpl::WaitForSurface() {
   TimeTicks timeout_time = start_time + time_left;
   while (1) {
     TRACE_EVENT0("renderer_host", "WaitForSurface::WaitForSingleTaskToRun");
-    if (ui::WindowResizeHelperMac::Get()->WaitForSingleTaskToRun(time_left)) {
+    if (ui::WindowResizeHelper::Get()->WaitForSingleTaskToRun(time_left)) {
       // For auto-resized views, current_size_ determines the view_size and it
       // may have changed during the handling of an UpdateRect message.
       if (auto_resize_enabled_)