@killjoy123987, could you please provide the sample test case for this issue , so that we can check this issue from chrome-TE end.

This gpu-acceleration behavior is by design. It is a performance heuristic. The idea is that there is a fixed cost overhead for each gpu-acclerated canvas, so small canvases are not usually worth accelerating.

I would like to make this issue about the performance of your specific web application rather than about the gpu turning off (that is not necessarily how we'll fix your problem).  Could you provide a URL, or attach a sample html file so that we can investigate your use case?

Hello, thanks for the speedy replies, I wrote a quick sample showing the issue, seems to be on a copy from a larger canvas/image to the smaller one, even if I'm only copying a small chunk (latency fetching the pixel data from the GPU I assume?), and not prerendering the tiles only makes it slower. On a mouse click the canvas's height changes from 206 to 205 and you can see the animation start to stutter. I only opened the bug because both Firefox and IE seem to use hardware acceleration on small canvases and I could not find any info besides a post on stackexchange mentioning it used to be like that for anything below 256x256 on Chrome/Chromium, and if it's by design I can work around it, Setting imageSmoothingEnabled to false for example decreased the render time of the pre-rendered map from ~60ms to ~30ms, and I can always switch to webgl if preformance becomes too much of a concern.

Deleted: TestCase-Canvas.zip 1.3 KB

TestCase-Canvas.zip 1.3 KB Download

Thanks for the info. A fix is on the way.

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

commit 2b0d65c9311d7e87784e90d60bfc68efb5f03555
Author: junov <junov@chromium.org>
Date: Tue Oct 04 17:36:28 2016

Disable GPU acceleration on 2D canvas when readbacks are needed

We are already disabling GPU acceleration to avoid readbacks caused
by calls to getImageData. This change applies the same principle
to canvas-to-canvas drawImage calls in order to avoid probable
future readbacks.

BUG= 652126 ,  651517 ,  650116 ,  642539 ,  640144 

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

[modify] https://crrev.com/2b0d65c9311d7e87784e90d60bfc68efb5f03555/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp
[modify] https://crrev.com/2b0d65c9311d7e87784e90d60bfc68efb5f03555/third_party/WebKit/Source/modules/canvas2d/CanvasRenderingContext2DTest.cpp
[modify] https://crrev.com/2b0d65c9311d7e87784e90d60bfc68efb5f03555/third_party/WebKit/Source/platform/graphics/ExpensiveCanvasHeuristicParameters.h

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

commit cec79c107fdef40fce38804b5851425959309f46
Author: junov <junov@chromium.org>
Date: Tue Oct 04 20:35:40 2016

Comment fixes in ExpensiveCanvasHeuristicParameters.h

Follow-up to post-vommit comment in:
https://codereview.chromium.org/2388293002/

TBR=senorblanco@chromium.org
BUG= 652126 

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

[modify] https://crrev.com/cec79c107fdef40fce38804b5851425959309f46/third_party/WebKit/Source/platform/graphics/ExpensiveCanvasHeuristicParameters.h