Chromium compositor change implementing page-scale driven pinch-zoom.

ui/compositor/compositor.cc

Index: ui/compositor/compositor.cc
===================================================================
--- ui/compositor/compositor.cc	(revision 160227)
+++ ui/compositor/compositor.cc	(working copy)
@@ -186,6 +186,8 @@
       command_line->HasSwitch(switches::kUIEnablePartialSwap));
   compositor_support->setPerTilePaintingEnabled(
       command_line->HasSwitch(switches::kUIEnablePerTilePainting));
+  compositor_support->setPageScalePinchZoomEnabled(
+      command_line->HasSwitch(switches::kEnablePinchInCompositor));

[piman, 2012/10/05 00:01:08]

Do we really want to pinch-zoom the UI?

[Jeff Timanus, 2012/10/05 00:05:34]

I'm not sure if I understand your question.  This particular call pushes the
switch state for the new flag to the compositor, which is used to selectively
enable my new pinch patch.

As I understand the implementation, the browser UI should never be scaled, only
the contents of the root scroll layer.

[piman, 2012/10/05 00:25:51]

This is the UI's compositor. Why are we doing anything to it?

[Jeff Timanus, 2012/10/05 15:37:50]

Ah.  It's possible that I did not understand the different compositor
environments.  I followed the existing flag behaviour to push the pinch state to
the compositor.

I don't think pinch should be relevant for the UI.  If I remove this call, and
rely on the similar path in content/renderer/render_thread_impl.cc, should that
suffice for only modifying the settings state of the web-contents compositor?

   if (use_thread)
     g_compositor_thread = new webkit_glue::WebThreadImpl("Browser Compositor");
   compositor_support->initialize(g_compositor_thread);