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

cc/resources/resource_provider.h

 // Copyright 2012 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_RESOURCES_RESOURCE_PROVIDER_H_
 #define CC_RESOURCES_RESOURCE_PROVIDER_H_
 
 #include <deque>
 #include <set>
 #include <string>
@@ skipping 394 matching lines @@
     int child_id;
     unsigned gl_id;
     // Pixel buffer used for set pixels without unnecessary copying.
     unsigned gl_pixel_buffer_id;
     // Query used to determine when asynchronous set pixels complete.
     unsigned gl_upload_query_id;
     TextureMailbox mailbox;
     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;
     linked_ptr<ImageRasterBuffer> image_raster_buffer;
     linked_ptr<PixelRasterBuffer> pixel_raster_buffer;
   };
   typedef base::hash_map<ResourceId, Resource> ResourceMap;
 
   class RasterBuffer {
    public:
@@ skipping 239 matching lines @@
   return format_gl_data_format[format];
 }
 
 inline GLenum GLInternalFormat(ResourceFormat format) {
   return GLDataFormat(format);
 }
 
 }  // namespace cc
 
 #endif  // CC_RESOURCES_RESOURCE_PROVIDER_H_