Decouple scheduling animation of webview plugins from layout.

third_party/WebKit/public/web/WebPluginContainer.h

Index: third_party/WebKit/public/web/WebPluginContainer.h
diff --git a/third_party/WebKit/public/web/WebPluginContainer.h b/third_party/WebKit/public/web/WebPluginContainer.h
index 569d190d7f16d89b876eda3f6fe22b6f68017ebf..47a0d37d5649a9edfa45c006acea52a7dd1d9407 100644
--- a/third_party/WebKit/public/web/WebPluginContainer.h
+++ b/third_party/WebKit/public/web/WebPluginContainer.h
@@ -65,11 +65,8 @@ public:
     virtual void invalidateRect(const WebRect&) = 0;
     virtual void scrollRect(const WebRect&) = 0;
 
-    // Causes the container to be marked as needing layout, which in turn will cause
-    // layoutIfNeeded() to be called on any contained WebPlugin during the container's
-    // web view's lifecycle update, and in particular before calling paint() on the
-    // WebPlugin.
-    virtual void setNeedsLayout() = 0;
+    // Schedules an animation of the WebView that contains the plugin, as well as the plugin.
+    virtual void scheduleAnimation() = 0;

[wkorman, 2016/03/08 01:38:50]

If this is the way a new frame is requested, perhaps we should consider renaming
scheduleAnimation at some point, since as currently named I suspect most would
guess it is solely css animation related.

[chrishtr, 2016/03/10 19:06:14]

In some cases it isn't even running a frame, it's running async
events for script such as onresize. Still not exactly sure what changes
should be made to clean up frames vs events, I am intending to ask
around to the scheduling team.

 
     // Causes the container to report its current geometry via
     // WebPlugin::updateGeometry.