@junov, is low end device regarding to the ones in Android? Is chromebook one of the low end devices?

This issue is targetting devices that are flagged as low end by base::SysInfo::IsLowEndDevice().

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e5f7fdd10814d38c50e90700d2cf67fec0b8bcd2

commit e5f7fdd10814d38c50e90700d2cf67fec0b8bcd2
Author: junov <junov@chromium.org>
Date: Fri May 26 20:47:26 2017

Reduce Canvas FontCache size on low end devices

BUG= 726462 

Review-Url: https://codereview.chromium.org/2907843002
Cr-Commit-Position: refs/heads/master@{#475117}

[modify] https://crrev.com/e5f7fdd10814d38c50e90700d2cf67fec0b8bcd2/third_party/WebKit/Source/core/html/canvas/CanvasFontCache.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5827cd0085ff673f5d89192761a4112e07dbb20c

commit 5827cd0085ff673f5d89192761a4112e07dbb20c
Author: Justin Novosad <junov@chromium.org>
Date: Fri May 26 21:11:30 2017

Disable 2D canvas deferred rendering on low end devices

BUG= 726462 

Change-Id: I6ac316b24308ae347042a56e90be5dee16a74e74
Reviewed-on: https://chromium-review.googlesource.com/516808
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Commit-Queue: Justin Novosad <junov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#475127}
[modify] https://crrev.com/5827cd0085ff673f5d89192761a4112e07dbb20c/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp
[modify] https://crrev.com/5827cd0085ff673f5d89192761a4112e07dbb20c/third_party/WebKit/Source/platform/graphics/GraphicsTypes.h
[modify] https://crrev.com/5827cd0085ff673f5d89192761a4112e07dbb20c/third_party/WebKit/Source/platform/graphics/RecordingImageBufferSurface.cpp
[modify] https://crrev.com/5827cd0085ff673f5d89192761a4112e07dbb20c/tools/metrics/histograms/enums.xml

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0fd268c608f2d2967c81b1deb1b521848ce2039a

commit 0fd268c608f2d2967c81b1deb1b521848ce2039a
Author: junov <junov@chromium.org>
Date: Fri May 26 22:53:17 2017

Disable display list 2d canvas on low-end devices

BUG= 726462 

Review-Url: https://codereview.chromium.org/2905903003
Cr-Commit-Position: refs/heads/master@{#475171}

[modify] https://crrev.com/0fd268c608f2d2967c81b1deb1b521848ce2039a/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp

I have optimized as far as I could for M61.  Here are the statuses of the various approaches that have been considered:

* Measure memory footprint of accelerated vs non-accelerated 2D canvas, adjust heuristics accordingly.
Outcome: disabling acceleration provides very modest RAM saving, at a high cost in terms of performance. Not worth it.

* Reduce size of skia’s ganesh cache.
Outcome: Done.  Cache size reduced from 96 to 48MB on low-end devices.
CL: https://codereview.chromium.org/2836063003/
* Disable deferred rendering in Canvas2DLayerBridge (to avoid locking large resources)
Outcome: Done. Save about 20% RAM on sprite based demos. CL: https://chromium-review.googlesource.com/516808
* Disable display-list-2d-canvas (to avoid locking large resources), or perhaps enable it more (to avoid backing store allocation)?  Probably needs an heuristic.
Outcome: Done. CL: https://codereview.chromium.org/2905903003
* Reduce size of CanvasFontCache
Outcome: Done. CL: https://codereview.chromium.org/2907843002
* Disable sw<->hw switches
Outcome: Rendering mode switch only have a transient memory cost and if there is not enough RAM to perform the switch, the switch is simply aborted. The current state of things seems acceptable.
* Flush GrContext frequently (after drawImage calls?)
Outcome: this was already achieved indirectly by reducing the limit of the ganesh cache size.  It turns out that resources locked by deferred draw opreations count against the cache limit, and flushes are automatically triggered when the limit is reached.
* Reduce bit depth (GL_RGBA4 , or GL_RGB565, depending on need for alpha).  Will result in color banding.  Not sure if skia can handle this.
Outcome: Abandoined. Attempted to implement this, but skia is lacking 4-4-4-4 format support for some of the draw and conversion operations that are required by 2D canvas.  Also, we realized that the loss of precision may be intolerable for several important use cases, such as apps that do image pre-processing (e.g. resizing) on the client side before uploading to the cloud. 

Quick question, for ganesh cache limit. Is it only for Canvas 2D? Or it will affect the normal page rendering.

The ganesh cache limit was only changed on the context that is used by 2D canvas. The ganesh context used by the compositor (for gpu rasterization) is independent of this.