cc: Support texture rect targets for masks

cc/trees/layer_tree_settings.h

Index: cc/trees/layer_tree_settings.h
diff --git a/cc/trees/layer_tree_settings.h b/cc/trees/layer_tree_settings.h
index c0c145380373eac2f770f491bf5f40b5cfea391f..5d61231f615a0e346702acdaa4416246934facc9 100644
--- a/cc/trees/layer_tree_settings.h
+++ b/cc/trees/layer_tree_settings.h
@@ -79,6 +79,13 @@ class CC_EXPORT LayerTreeSettings {
   bool use_occlusion_for_tile_prioritization;
   bool record_full_layer;
 
+  enum TextureTargetPrefs {
+    USE_DEFAULT_TEXTURE_TARGET,
+    FORCE_TEXTURE_2D_TARGET,
+    FORCE_TEXTURE_RECT_TARGET,

[reveman, 2014/10/22 12:40:39]

I think TEXTURE_EXTERNAL_OES should be part of this too. 

+  };
+  TextureTargetPrefs texture_target_prefs;

[reveman, 2014/10/22 12:40:39]

I'd prefer if this was not a preference or override but our real texture target
selection mechanism and the code to set it replaces any logic we currently have
to determine what target to use. This requires having access to
ContextProvider::Capabilities at the time we initialize this setting so this
suggestion might be misguided if that's not the case. 

[enne (OOO), 2014/10/22 19:20:44]

The problem here is conflicting requirements.  Production code wants to be
flexible in the face of different capabilities.  Test code wants to be strict to
make sure that it's actually testing what it's testing and these preferences
aren't flexibly ignored.

How do you combine those two needs? Your solution helps with the flexiblity, but
I doesn't meet the testing need.

[reveman, 2014/10/22 20:36:48]

Hm, can we adjust capabilities for our testing needs instead of adding this
setting?

[enne (OOO), 2014/10/22 21:14:30]

How does this meet the testing need? A test could specify texture rect
capability or not, but adding texture rect capability doesn't mean that it will
be used.

What I want is some way to know for sure that the different GLRenderer paths for
tile contents and mask contents get exercised.

[reveman, 2014/10/22 23:25:19]

We should probably add a new capability field for what target is supported with
CHROMIUM_image instead of picking external_oes if available, then rectangle_arb
if available and then fallback to 2d. That just happens to work but there's not
really a guarantee that rectangle_arb or 2d is supported if external_oes is not.

capability.image_texture_target might be what we need.

+
   LayerTreeDebugState initial_debug_state;
 };