Delay UpdateRect until the SwapBuffers callback when accelerated compositing is on.

content/common/view_message_enums.h

Index: content/common/view_message_enums.h
diff --git a/content/common/view_message_enums.h b/content/common/view_message_enums.h
index f1538c8fc88b586960f18fd4e817a89088ef4134..a9a49341e0c7990d028088da5009b76b9dac887e 100644
--- a/content/common/view_message_enums.h
+++ b/content/common/view_message_enums.h
@@ -103,6 +103,7 @@ struct ViewHostMsg_UpdateRect_Flags {
     IS_RESIZE_ACK = 1 << 0,
     IS_RESTORE_ACK = 1 << 1,
     IS_REPAINT_ACK = 1 << 2,
+    NEEDS_ACK = 1 << 3,
   };
   static bool is_resize_ack(int flags) {
     return (flags & IS_RESIZE_ACK) != 0;
@@ -113,6 +114,9 @@ struct ViewHostMsg_UpdateRect_Flags {
   static bool is_repaint_ack(int flags) {
     return (flags & IS_REPAINT_ACK) != 0;
   }
+  static bool needs_ack(int flags) {

[darin (slow to review), 2011/11/15 08:06:04]

it seems a bit awkward to put this flag here.  the above three bits are
indicating that a ViewHostMsg_UpdateRect IPC is in response to a Resize, Restore
or Repaint request made by the browser.  here, needs_ack is saying whether an
UpdateRect_ACK message should be sent in reply to the UpdateRect message.  this
ack has nothing to do with the other acks.

this perhaps suggests that needs_ack should really be part of the
UpdateRect_Params structure as a boolean member.

counterargument:  this member of UpdateRect_Params is named "flags", which is a
very generic sounding field.  that naming seems to welcome putting other bits in
as flags as you have done.  so perhaps i'm a bit torn.  it took me a while to
mentally separate the IS_{RESIZE,RESTORE,REPAINT}_ACK bits from the NEEDS_ACK
bits.  they are completely unrelated and yet look like they must be related :-(

[piman, 2011/11/16 01:00:55]

Done.

+    return (flags & NEEDS_ACK) != 0;
+  }
 };
 
 struct ViewMsg_Navigate_Type {