cc: Reduce size of cc::ResourceProvider::Resource class

cc/resources/resource_provider.h

Index: cc/resources/resource_provider.h
diff --git a/cc/resources/resource_provider.h b/cc/resources/resource_provider.h
index 73b5a23dcdf3c249f075946ce7a0c6deb77ac0d6..6c952aeece80cb43dbefa9736986b966d5d94dc6 100644
--- a/cc/resources/resource_provider.h
+++ b/cc/resources/resource_provider.h
@@ -412,32 +412,32 @@ class CC_EXPORT ResourceProvider {
     ReleaseCallback release_callback;
     uint8_t* pixels;
     uint8_t* pixel_buffer;
-    int lock_for_read_count;
-    int imported_count;
-    int exported_count;
-    bool locked_for_write;
-    Origin origin;
-    bool marked_for_deletion;
-    bool pending_set_pixels;
-    bool set_pixels_completion_forced;
-    bool allocated;
-    bool enable_read_lock_fences;
+    uint16 lock_for_read_count;

[danakj, 2014/03/21 16:04:22]

style guide says to use signed int except for things like size of an array which
returns size_of.

[jadahl, 2014/03/21 16:54:51]

I suppose a 16 bit signed int should be enough as well?

+    uint16 imported_count;
+    uint16 exported_count;
+    unsigned image_id;
+    unsigned bound_image_id;
+    bool dirty_image : 1;

[danakj, 2014/03/21 16:04:22]

Do you have any data to show this affects our performance?

[jadahl, 2014/03/21 16:54:51]

No, I have not done any measurements; do you really think this change could have
a measurable effect? Are the fields are already placed in order to optimize
cache behavior (I couldn't see that it was)?

[danakj, 2014/03/21 18:04:01]

No, they're not placed in any specific order. I don't mind moving things around
to pack them nicely, but I feel more resistant to CLs that nitpick at the size
of fields in structs without some data to show an improvement. Cuz there are an
infinite number of CLs that could be submitted to tweak the sizes of various
fields all over the place. And it would probably be mostly a waste of time, you
know?

[jadahl, 2014/03/24 09:54:27]

The data I have is that I measured the maximum number of active instances
rendering; and how much less memory this struct would theoretically use by
making the size smaller. When I did the measurements the struct was smaller to
begin with, and the size improvement smaller, and at that time some (~6 KiB)
memory would *theoretically* be saved.

I could remove the uint16 bit if you'd like the ": 1" and grouping of bools, and
we'd still get a small improvement. It is not a big improvement, so we could
drop it as well if that what you think is the best option.

+    bool locked_for_write : 1;
+    bool lost : 1;
+    bool marked_for_deletion : 1;
+    bool pending_set_pixels : 1;
+    bool set_pixels_completion_forced : 1;
+    bool allocated : 1;
+    bool enable_read_lock_fences : 1;
+    bool has_shared_bitmap_id : 1;
     scoped_refptr<Fence> read_lock_fence;
     gfx::Size size;
+    Origin origin;
     GLenum target;
     // TODO(skyostil): Use a separate sampler object for filter state.
     GLenum original_filter;
     GLenum filter;
-    unsigned image_id;
-    unsigned bound_image_id;
-    bool dirty_image;
     GLenum texture_pool;
     GLint wrap_mode;
-    bool lost;
     TextureUsageHint hint;
     ResourceType type;
     ResourceFormat format;
-    bool has_shared_bitmap_id;
     SharedBitmapId shared_bitmap_id;
     SharedBitmap* shared_bitmap;
     linked_ptr<DirectRasterBuffer> direct_raster_buffer;