Bug 778036 - Only notify the parent of the first TabChild paint. r=cjones

dom/ipc/TabChild.cpp

@@ -103,6 +103,7 @@ TabChild::TabChild(PRUint32 aChromeFlags, bool aIsBrowserElement,
   , mLastBackgroundColor(NS_RGB(255, 255, 255))
   , mDidFakeShow(false)
   , mIsBrowserElement(aIsBrowserElement)
+  , mNotified(false)
   , mAppId(aAppId)
 {
     printf("creating %d!\n", NS_IsMainThread());
@@ -1269,17 +1270,9 @@ TabChild::SetBackgroundColor(const nscolor& aColor)
 void
 TabChild::NotifyPainted()
 {
-    if (UseDirectCompositor()) {
-        // FIXME/bug XXXXXX: in theory, we should only have to push a
-        // txn to our remote frame once, and the
-        // display-list/FrameLayerBuilder code there will manage the
-        // tree from there on.  But in practice, that doesn't work for
-        // some unknown reason.  So for now, always notify the content
-        // thread in the parent process.  It's wasteful but won't
-        // result in unnecessary repainting or even composites
-        // (usually, unless timing is unlucky), since they're
-        // throttled.
+    if (UseDirectCompositor() && !mNotified) {
         mRemoteFrame->SendNotifyCompositorTransaction();
+        mNotified = true;
     }
 }
 

dom/ipc/TabChild.h

@@ -316,6 +316,7 @@ private:
     ScrollingBehavior mScrolling;
     bool mDidFakeShow;
     bool mIsBrowserElement;
+    bool mNotified;
     PRUint32 mAppId;
 
     DISALLOW_EVIL_CONSTRUCTORS(TabChild);