Implementation of device metrics emulation in render view.

content/browser/renderer_host/render_widget_host_view_aura.cc

Index: content/browser/renderer_host/render_widget_host_view_aura.cc
===================================================================
--- content/browser/renderer_host/render_widget_host_view_aura.cc	(revision 221161)
+++ content/browser/renderer_host/render_widget_host_view_aura.cc	(working copy)
@@ -808,6 +808,7 @@
   if (!host_->should_auto_resize() &&
       !resize_lock_.get() &&
       desired_size != current_frame_size_ &&
+      !device_emulation_enabled_ &&

[aelias_OOO_until_Jul13, 2013/09/13 23:51:44]

Is it really that you want to accept an image of *any* size?  It seems to me you
still expect a particular size, just a different one than usual?  Could you set
up the code that way instead?

Secondly, is a different size buffer needed in the first place now that you're
applying scale on the renderer side?

Generally speaking, rather than adding a new boolean mode that turns off some
logic, it would be better for the existing code to be refactored and generalized
to cover both your use case and the normal one.

[dgozman, 2013/09/14 07:42:42]

I think, this would be a right choice.
To supply image of required size we probably need a new root layer filled with
background color under the contents. I'm afraid that will break many things
assuming that root layer is what passed from blink.

[aelias_OOO_until_Jul13, 2013/09/14 07:50:53]

Not necessarily.  First, note that CC is rather flexible about taking any kind
of layer structure because it's also used for Aura windowing.  But I think you
should actually be able to get this working without changing the layer structure
by taking advantage of AppendQuadsToFillScreen() in layer_tree_host_impl.cc,
which is designed to deal with such cases where the layers don't fill the entire
screen.

I recommend giving that a try.  The RWHV resize logic is rather subtle and
bug-prone, and it would be nice to handle the sizing issues entirely within
renderer CC.

[aelias_OOO_until_Jul13, 2013/09/14 08:06:51]

On second thought, the real difficulty if you go that route would be to separate
the scroll and draw viewports, i.e. you would be forced to create a new
OutputSurface type and use SetExternalDrawConstraints from it.  It's not obvious
that's a better architecture than the one you're currently going with, it may
well be worse.  So I withdraw that suggestion for now, please go ahead and clean
up the resize-based stuff like we were saying.

[dgozman, 2013/09/19 10:17:11]

Done.

       host_->is_accelerated_compositing_active()) {
     aura::RootWindow* root_window = window_->GetRootWindow();
     ui::Compositor* compositor = root_window ?
@@ -2002,6 +2003,10 @@
     touch_editing_client_->GestureEventAck(gesture_event_type);
 }
 
+void RenderWidgetHostViewAura::EmulateDevice(bool enabled) {
+  device_emulation_enabled_ = enabled;
+}
+
 void RenderWidgetHostViewAura::ProcessAckedTouchEvent(
     const TouchEventWithLatencyInfo& touch, InputEventAckState ack_result) {
   ScopedVector<ui::TouchEvent> events;