TaskGraphRunner Group support

cc/raster/task_category.h

Index: cc/raster/task_category.h
diff --git a/cc/raster/task_category.h b/cc/raster/task_category.h
new file mode 100644
index 0000000000000000000000000000000000000000..1a7667490aef86cea8f10228c696afa0bb1e544d
--- /dev/null
+++ b/cc/raster/task_category.h
@@ -0,0 +1,24 @@
+// Copyright 2015 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_RASTER_TASK_CATEGORY_H_
+#define CC_RASTER_TASK_CATEGORY_H_
+
+#include <cstdint>
+
+namespace cc {
+
+// A set of values used by CC and its consumers to categorize tasks within the
+// TaskGraphRunner.
+enum TASK_CATEGORY : uint16_t {
+  TASK_CATEGORY_SYNCHRONOUS_HIGH_PRIORITY = 0,
+  TASK_CATEGORY_HIGH_PRIORITY = 1,
+  TASK_CATEGORY_LOW_PRIORITY = 2,
+};

[reveman, 2015/12/10 16:49:57]

This look good but I'd rather not have any task graph runner implementations
assume that these are the only valid values. I thinking of this as more of a
hint which it's perfectly fine by an implementation to ignore. Just like it's
fine to ignore the priority of tasks. What I'm really trying to say is that I
don't think we should have the kNumTaskCategories below.

Would it help to just expose TaskGraphWorkQueue::ready_to_run_namespaces_ to the
TGR implementations? Add a "ready_to_run_namespaces() const { return
ready_to_run_namespaces_; }" getter? As the work queue is just some helper
function I feel like that would be ok.

+
+enum : uint16_t { kNumTaskCategories = TASK_CATEGORY_LOW_PRIORITY + 1 };
+
+}  // namespace cc
+
+#endif  // CC_RASTER_TASK_CATEGORY_H_