[Webkit-unassigned] [Bug 236173] New: Big drop in canvas performance above 3840px

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=236173

            Bug ID: 236173
           Summary: Big drop in canvas performance above 3840px
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Canvas
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: webkit_org at zdanowski.pro
                CC: dino at apple.com

Created attachment 450976

  --> https://bugs.webkit.org/attachment.cgi?id=450976&action=review

FPS vs canvas size

**Background**
While working on a complex full-screen 2D animation utilizing multiple <canvas> layers I found out a problem with Safari. The rendering performance drops sharply after the canvas gets bigger than exactly 3840x3840. I ran multiple tests (benchmark I wrote: https://codepen.io/kiler129/full/Exbgrqp) and obtained this peculiar graph attached to this bug report.

To make this graph I used:
 - MacBook Pro (2021, 16" M1 Max version): tried Safari 15.3 (17612.4.9.1.5), Safari TP Release 139 (Safari 15.4, WebKit 17613.1.14.41.3), as well as latest build of WebKit (r289148) on Monterey (12.2 (21D49))
 - Brave running on the MBP with macOS mentioned above
 - iPad Pro (3rd, 2018), running iOS 15.0


**Data analysis**
 - Steady 60 FPS/realtime is kept until 3840x3840, then it drops to unusable 2-25 FPS
 - There's a correlation between larger fill % (100% vs 20%) of the canvas and FPS, as well as larger number of draw calls per frame (d/f) and FPS -> nothing unusual here, it's pretty linear
 - Buffered canvases (drawing to off-screen & then copying) are way less performant for simple operations
 - Brave, and any other Chromium-based browsers, keep steady 60 FPS basically forever (even with screen-scaled 10000x10000 plane)
 - 2018 iPad running Safari behaves identically to 2021 MBP with M1 Max, just a little bit slower overall
 - The 3840px is exactly 4K. While I have a 4K monitor disconnecting it and rebooting doesn't change the steep drop point (MBP has a 3456x2234 screen). Even assuming that the 4K resolution is cached somewhere this doesn't explain the same drop on the iPad which has nothing to do with 4K screens.

I also checked what actually takes time in Safari and it seems that the rendering to the screen and not the actual drawing on canvas is the culprit. That will explain why using buffering gives such bad results. The times for drawing are actually slower on Chromium-based browsers, yet the times are hardly correlated to anything, i.e. the calls like fillRect() are fast regardless of the size but the actual paint is getting VERY slow.


**Hardcoded size?**
This to me looks weird, like WebKit has some hardcoded 3840px boundary and switches how it renders <canvas> with 2D context above that size. Unfortunately that switch absolutely kills the performance.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220205/a93b0ffc/attachment.htm>