Canvas performance is poor when drawing on large canvases. On OSX, using both Skia and CG, CopyableCanvasLayer dominates execution time. Is the copy operation of the Canvas buffer absolutely necessary? Perf is a lot better when gfx.canvas.azure.accelerated is true.

Jet is following up with the gfx team.

Current results with Chrome, Nightly 49 (false), Nightly 49 (true): 1024 - 60 fps, 59 fps, 60 fps 2048 - 60 fps, 58 fps, 60 fps 3072 - 60 fps, 29 fps, 60 fps 4096 - 60 fps, 18 fps, 58 fps 5120 - 27 fps, 11 fps, 13 fps [2] 6144 - 11 fps, FAIL [1], FAIL [1] 1. Nightly 49 with the pref set to false failed soon after processing 5120, showing a black content window and sending "###!!! [Child][DispatchAsyncMessage] Error: (msgtype=0xFFFB,name=???) Payload error: message could not be deserialized. [GFX1-]: Failed to create a valid ShmemTextureHost" to stdout. The same result was witnessed with the pref set to true although it seemed to make it further into the test. 2. Nightly 49 with the pref set to true started sending "[GFX1-]: Failed to create a SkiaGL DrawTarget, falling back to software" to stdout soon after processing 5120, although the test visibly continued.

I can reproduce the perf issue on windows and mac. I got 3x or more slower than chrome on windows. The creation failure in '6144' should be due to the limitation of "gfx.max-alloc-size". There is a related bug 1282074. SkiaGL has another limitation of surface size [1], so it falls back to software. For current canvas implementation, gecko always copies the whole surface to the backbuffer when updating[2]. I think this might be the problem, but it's limited by the current architecture. I'll think how to improve it. [1] https://dxr.mozilla.org/mozilla-central/source/gfx/2d/DrawTargetSkia.h#148 [2] https://dxr.mozilla.org/mozilla-central/source/gfx/layers/CopyableCanvasLayer.cpp#88

(In reply to Ethan Lin[:ethlin] from comment #3) > I can reproduce the perf issue on windows and mac. I got 3x or more slower > than chrome on windows. The creation failure in '6144' should be due to the > limitation of "gfx.max-alloc-size". There is a related bug 1282074. SkiaGL > has another limitation of surface size [1], so it falls back to software. > For current canvas implementation, gecko always copies the whole surface to > the backbuffer when updating[2]. I think this might be the problem, but it's > limited by the current architecture. I'll think how to improve it. > > [1] > https://dxr.mozilla.org/mozilla-central/source/gfx/2d/DrawTargetSkia.h#148 > [2] > https://dxr.mozilla.org/mozilla-central/source/gfx/layers/ > CopyableCanvasLayer.cpp#88 As bug 1161636 comment 1, those steps should be able to reduce the copy times. I also found memory leakage in this test case. I'll file another bug to fix it.

There is some work to remove unnecessary canvas copies that started with a large architectural change in bug 1167235 and is more generally tracked with bug 1290072. This work is not enabled by default everywhere yet but will be soon as we figure out the various regressions. My expectation is that we'll be in a much better when these optimizations get enabled (currently behind the pref layers.shared-buffer-provider.enabled). That said, there are different ways to use canvas and some will trigger optimizations and some won't. For example we will be able to detect that the first drawing operation in a frame covers the entire canvas and be able to skip a copy of the full canvas. I am mentioning this because it makes it less evident to create minimal test cases that reflect what real web content do since it's not obvious that a ClearRect can optimize away a full copy. I don't want to add more complexity (CanvasRenderingContext2D is already quite a mess) for an artificial test case if it does not reflect real world uses of canvas 2D, so it would be good to mention examples of real sites that are impacted in addition to the test cases to be sure that the latter do reflect the real problems we are trying to solve. In this case for example, it would be interesting to know if many sites create very large canvases and render animations in them over the content of previous frames (without clearing first).