cc: Support texture rect targets for masks

cc/trees/layer_tree_settings.h

 // Copyright 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CC_TREES_LAYER_TREE_SETTINGS_H_
 #define CC_TREES_LAYER_TREE_SETTINGS_H_
 
 #include "base/basictypes.h"
 #include "cc/base/cc_export.h"
 #include "cc/debug/layer_tree_debug_state.h"
@@ skipping 61 matching lines @@
   int highp_threshold_min;
   bool strict_layer_property_change_checking;
   bool use_one_copy;
   bool use_zero_copy;
   bool ignore_root_layer_flings;
   bool use_rgba_4444_textures;
   size_t texture_id_allocation_chunk_size;
   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;
 };
 
 }  // namespace cc
 
 #endif  // CC_TREES_LAYER_TREE_SETTINGS_H_