Fixing laggy chrome on a multitude of accelerated canvases

third_party/WebKit/Source/core/html/HTMLCanvasElement.h

Index: third_party/WebKit/Source/core/html/HTMLCanvasElement.h
diff --git a/third_party/WebKit/Source/core/html/HTMLCanvasElement.h b/third_party/WebKit/Source/core/html/HTMLCanvasElement.h
index f208f37cd8c8b58d3b37059210374440d256c221..cb3c31b21a4ede1b5a2d94ba360a12e3e434f436 100644
--- a/third_party/WebKit/Source/core/html/HTMLCanvasElement.h
+++ b/third_party/WebKit/Source/core/html/HTMLCanvasElement.h
@@ -169,6 +169,7 @@ public:
 
     static void registerRenderingContextFactory(PassOwnPtr<CanvasRenderingContextFactory>);
     void updateExternallyAllocatedMemory() const;
+    static void updateTotalMemoryForAcceleratedCanvases(intptr_t diffFromCurrAllocatedMemory);
 
     void styleDidChange(const ComputedStyle* oldStyle, const ComputedStyle& newStyle);
 
@@ -209,7 +210,8 @@ private:
     FloatRect m_dirtyRect;
 
     mutable intptr_t m_externallyAllocatedMemory;
-
+    static intptr_t s_totalMemoryForAcceleratedCanvases;

[danakj, 2015/11/30 23:07:03]

I would maybe suggest tying this to a single blink (or canvas) instance rather
than the whole process. There may be multiple tabs in the same process, that are
all visible. And usually you'd want them to each have their own budget, probably
(compositors would). Maybe junov has thoughts here.

[xlai (Olivia), 2015/12/01 21:50:25]

I did some experiments and confirmed that this variable is keeping track of each
browser tab's own usage separately; so it's not a "total" computation of all
tabs. 

[danakj, 2015/12/01 22:13:35]

Chrome will put tabs in different processes in different ways, depending how you
launched the tab (from a js link = same process) and on diff platforms (on
android almost all tabs share one process.. maybe they all do)

+    
     bool m_originClean;
 
     // It prevents HTMLCanvasElement::buffer() from continuously re-attempting to allocate an imageBuffer