Bug 209802

Summary: Performance issue with the canvas "globalCompositeOperation" when set to "destination-in"
Product: WebKit Reporter: register
Component: CanvasAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Major CC: ap, dino, sabouhallawa, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 13   
Hardware: Mac   
OS: macOS 10.14   
Attachments:
Description Flags
A stand-alone sample file which demonstrates the issue none

Description register 2020-03-31 05:20:45 PDT 
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).
Comment 1 Alexey Proskuryakov 2020-03-31 11:47:27 PDT 
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.
Comment 2 Radar WebKit Bug Importer 2020-03-31 11:51:41 PDT 
<rdar://problem/61118198>
Comment 3 register 2020-03-31 13:06:15 PDT 
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.
Comment 4 register 2020-03-31 13:09:01 PDT 
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.
Comment 5 Simon Fraser (smfr) 2020-03-31 13:46:49 PDT 
There's some extra read back happening. Need to figure out why; it might be beneath WebKit.
Comment 6 register 2020-05-19 02:07:51 PDT 
Hello.

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

Thank you.
Comment 7 Simon Fraser (smfr) 2020-05-19 11:09:01 PDT 
I did not, sorry. This involves digging deep into Apple frameworks.
Comment 8 register 2020-05-20 23:51:58 PDT 
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?