Bug 209802 – Performance issue with the canvas "globalCompositeOperation" when set to "destination-in"

• Status: NEW
• Component: Canvas

Created attachment 395026 [details]
A stand-alone sample file which demonstrates the issue

On a canvas "CanvasRenderingContext2D" 2D context, when using the "globalCompositeOperation" with the value "destination-in", but also the "source-in", "source-out" and "source-atop" values (all possible values referred at https://developer.apple.com/documentation/webkitjs/canvasrenderingcontext2d/global_compositing_operation_constants have been assessed), we notice a performance penalty with a magnitude of 10 compared to other values (in particular with the "destination-out".

This occurs at least on macOS 10.3, 10.4, in Safari 12, 13 and "Technology Preview".

This performance issue causes a severe harm to fluid animations. 

We have designed and attached a stand-alone HTML page which demonstrates the issued (we are aware that the "performance.now()" function does not have a precision below the millisecond, but since the "globalCompositeOperation" parameter set to one of the value which causes performance issue causes a response type over 10 ms, this lack of accuracy does not prevent from revealing the issue).

[Alexey Proskuryakov]

When running the test on a 16" MacBook Pro, I get values that seem to be all over the place. What is a pass and what is a failure for this test?

sum = 22 ms => average = 0.22 ms
sum = 11.000000000007276 ms => average = 0.11000000000007276 ms
sum = 3.000000000014552 ms => average = 0.030000000000145518 ms
sum = 20 ms => average = 0.2 ms
sum = 10 ms => average = 0.1 ms

destination-out doesn't seem to be much faster. This is Safari 13.1 on macOS 10.15.4.

[Radar WebKit Bug Importer]

<rdar://problem/61118198>

On a 15'' MacBook Pro, mid-year, I can confirm that the performance on the composition mode "destination-out" are 10 times better than with "destination-in", which seems very weird, due to the fact that the computation should be quite similar, in terms of complexity…

This is why I reported the issue, I hope that the WebKit team will handle this with great attention, because this strange performance behavior harms the UX.

As a side note, as a comparison, on the same machine equipped with a Chromium v80, the performances are quite similar with both composition modes, and about twice faster than Safari.

And beware of the results given by the little benchmark attached, because the "performance.now()" implementation on Safari does not allow sub-milliseconds precision. In order to work this around, if you have the opportunity to enable in Safari development mode the "performance.now()" sub-milliseconds precision (I could not find a way to achieve this), you will get precise results this time.

[Simon Fraser (smfr)]

There's some extra read back happening. Need to figure out why; it might be beneath WebKit.

Hello.

Did you have the time to investigate furthermore? Do you have some news to share regarding this performance issue, please?

Thank you.

[Simon Fraser (smfr)]

I did not, sorry. This involves digging deep into Apple frameworks.

OK, I understand that the issue involves a thorough investigation on the OS level. However, the performance penalty has some very noticeable impact. Should I open a ticket / bug somewhere else so that someone / some team investigated on it, please?

[Karl Dubost]

*** Bug 278454 has been marked as a duplicate of this bug. ***

[Karl Dubost]

Nice test case in Bug 278454 by Alf Eaton 
https://codepen.io/invisiblecomma/pen/poXLPaZ

with rendering differences in different browsers.
https://bugs.webkit.org/attachment.cgi?id=472262