iOS 15 Experimental WebKit Features: GPU Process: Canvas Rendering

Hello,

Just wondering if any folks have insight on one of the new experimental features that is enabled by default on the latest betas for iOS 15.

As indicated in this thread, the GPU Process: Canvas Rendering feature seems to be causing Safari issues for those with web applications that rely heavily on canvas interactions.

Is it normal for beta versions of iOS to include and enable additional experimental features? Should it be assumed that it's going to be live and enabled as default as part of the upcoming iOS release?

Alternatively -- does anyone know what exactly this experimental feature is doing? I haven't been able to find any documentation or explanation of its behavior so far.

Thanks!

  • This new feature completely broke my app - which is a WKWebView with a large canvas. Performance is incredibly slow renders the app useless. Worked great in iOS 14..

    How can we disable this setting in a WKWebView?

Add a Comment

Replies

Hi!

Options that appear in the Experimental Features menu, though accessible in Safari releases, is most useful for Safari Technology Preview where it allows web developers to try out in-development features and provide early feedback. It also gives WebKit engineers a mechanism to enable or disable certain features for testing during development. Experimental features that are not ready for developer testing are disabled by default. When they are ready to be tested and used, they become enabled by default.

Safari releases also include the Experimental Features menu with experimental features that are enabled by default. They remain in the menu until the Experimental Feature menu support is removed. Engineers use the mechanism in released Safari versions to enable and disable features for their own testing needs. Often, but not always, entries that are enabled by default in a beta will remain that way until the final releases ship.

The GPU Process: Canvas Rendering feature uses new architecture to support canvas rendering that occurs in a new GPU process instead of the Web Content process.

Post not yet marked as solved Up vote reply of jond Down vote reply of jond
  • This feature is live in iOS 15.0.1, and is affecting my web app's ability to capture a element feed by injecting it into a canvas.

    Is there any word on a fix, or if the experimental feature will be disabled in a future release?

Add a Comment

Hi,

I work with pmeskers. We are a little unclear about "will remain that way until the final releases ship" Does this mean that when it ships this setting will change or that the setting that is active in the beta usually ships to everyone. I'm not holding you to anything but our app is crashing browser tabs because of this features just trying to establish if we should work on this which likely involves some pretty deep rewrites.

Our app is decoding video (mp4) and GIFs in WebAssembly and converting them into JPEGs and PNGs (on the CPU) in workers and then rendering to canvas elements. From my understanding the GPU is taking over when we are drawing these images into the canvas with drawImage. New GPU textures will be created on every drawImage call for every layer on every frame. Videos and GIFs with more frames cause more memory pressure and at some point something is tripping because we are consuming too many resources. From my understanding, with current canvas rendering this isn't an issue because the GPU textures are not being made, the frame images are stored and passed through every frame without the extra step. But maybe I'm totally off about what the difference is here and how this is working?

If you are at some point in the future shipping this feature without patches that prevent the issues above is there anything that we can do to optimize our approach? For instance I see that ImageBitmap is now supported in Safari, would this be a solution rather than saving JPEG and PNG image caches or would this internally work the same as our current approach? Is there something else we can do to protect our browser tabs from crashing or any specific ways that we can debug exactly why these crashes that are happening when this flag is turned on?

After more testing we've found temporary work arounds by reducing the quality and choosing static textures in place of animated ones on iOS until we find something that works better.

For us these issues seems to be related to larger video textures 1024x1024 and createPattern being repeatedly updated. We manage dirty states for all of this and slow time down when we detect slow rendering update rates and never try updates faster than 30fps. So these calls were only happening when needed and only as fast as requestQuestAnimation frame said it was ready or slower.

By lowering our texture sizes to 512x512 and only calling createPattern once (taking out animations) these changes enable our site to not crash tabs but it has lowered the quality of what we can show to users on iOS and are still going to keep looking deeper into other fixes. We would love suggestions if you have any.

  • Talltyler thanks very much for these writeups. I'm following exactly in your footsteps and I can confirm that createPattern on large Canvas objects (2048x2048 in our case) is indeed a recipe for failure. I'm going to try to create a jsFiddle.

Add a Comment

Is it possible to disable this feature in wkwebkit. we can only disable it from safari setting. almost all of html5 games is broken due to this feature.

  • almost all of html5 games are affected. if you use canvas, your game will be broken for sure. no solution for now to turn off via wkwebkit. Thanks to apple, we all ****** up

  • Yes and even if things appear to work - try background app/web page then foreground .. then it really breaks.

  • I give apple million thanks…… it is totally ****** up

Add a Comment

Hi, we have the same problem with a large canvas rendered file. Is there a way to turn off this feature on macOS? Our users usually use a Mac and not an iPad.

Hi, we have the same problem with a large canvas rendered file. Is there a way to turn off this feature on macOS? Our users usually use a Mac and not an iPad.

Any updates? 15.2 is near and this is still broken.

  • We're experiencing the same issues. Disabling this feature seems to get our products back working. While that's encouraging, those configuration changes apparently cannot be handled by AirWatch, which is a tool popular amongst our institutional customers. Would be really nice to get things back working & we await a fix from Apple. Is anyone aware of plans to default to known working technology rather than pushing something marked as "experimental" on the broader market?

  • Any idea on how we can disable this feature by code.

  • @cj9956 still looking for the same but no luck.

Hey, my phone was over heating to the point where it was hot to the touch. I turned everything down, and threw on airplane mode. Immediately I checked the settings. Started turning off those experimental features, and my phone cooled right down. I don't believe it is necessary for me.. Heat damages electronics in excess, hopefully that isn't the case with my phone now