Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

94
Views
Safari: big drop in <canvas> performance above certain fixed 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:

fps vs canvas size (click for a readable full-size copy)

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:

draw time vs canvas size

Why such a large canvas?!

To avoid X-Y problem situation, I'm answering this ahead of time. I stumbled upon this issue in a real-world tests and then prepared the benchmark trying to eliminate all variables from the real-world application. 3840px is perfectly reasonable when used on HiDPI/"retina" displays; with x2 scaling it gives 1920px screen real estate which is quite normal. While the benchmark clips the viewport the real code doesn't (it doesn't seem to make a measurable difference).

Bug?

Is there anything I can do here, or this is a some sort of a limitation/bug of the WebKit/Safari? While testing the Safari doesn't crash but window becomes very unresponsive until the rendering is stopped.

The only solution I see is detecting FPS drop and disabling retina scaling on Safari.

about 4 years ago · Juan Pablo Isaza
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!