Based on the current iOS 14 beta (beta 7) the performance of texImage2d from a video element has suffered a significant regression since iOS 13.
Some examples pages that have the very simplest shader and render loop for getting a 720p video into a WebGL canvas:
https://tango-bravo.net/WebGLVideoPerformance/texImage2d_video.html (uses gl.RGB format and internal format)
https://tango-bravo.net/WebGLVideoPerformance/texImage2d_video_rgba.html (uses gl.RGBA format and internal format)
On an iPod 7th gen running iOS 13.6, I've observed the reported total average draw time under 2ms for both of these and it has no difficulty maintaining a 60FPS render loop (aside: iOS seems to downclock when hitting 60FPS; opening the app switcher and interacting with the page (scrolling, zooming, etc) looks to bring the timings down).
With an iPhone XR on the iOS 14 beta 7, things are significantly worse. With the first example the render loop drops under 60 FPS (and the bulk of the time seems to be spent in drawElements). With the RGBA format (second link) 60 FPS is maintained but the timings remain high (above 7ms).
Could you please clarify if this affects user facing websites or apps?
As demonstrated by the test case, any page making use of video textures for WebGL will suffer a performance regression.
Here's a user-facing site that is affected. It's a regression test (with a 1080p video) for our web-based AR platform that shows very poor performance in the beta on an iPhone XR, but is perfectly smooth on the iOS 13 iPod 7th gen.
Both camera and video textures go via texImage2d from video elements. The black flashing background appears to be another WebGL related regression in iOS 14 that I'm currently attempting to make a minimal test case for so I can submit another bug report.
Most higher-res video content would use HLS, so clearly Bug 215908 is a bigger priority and breaks many live WebGL sites. However it seems whatever changes have been made to the WebGL video texture pipeline even outside of HLS have a significant performance impact too.
I can also replicate this regression on https://my.panomoments.com/u/dustinkerstein/m/grand-central using a first generation iPad Pro on the iPadOS 14 GM. With the UHD and HD resolutions the render framerate is about 25-50% of what I see on iPadOS 13.
Here is a pure WebGL-based JSFiddle that should replicate on iOS/iPadOS (though you should make sure to click into the preview window to avoid an iFrame iOS power saving feature) - https://jsfiddle.net/1obyw68k
I believe I'm also able to replicate this regression in YouTube's 360 viewer, but I no longer have a test device on iOS 13 so I can't directly compare performance.
Here's a more generic WebGL texture upload test using a benchmark video that contains solid colors - https://jsfiddle.net/qz9ka6xm
The test uses gl.readPixels to count how many unique colors are rendered and the average upload time. I'm only able to get the 1080p test running on my iOS devices (I believe due to the aspect ratio of the 2160p file going beyond the mobile WebGL texture size limits - I can fix that if so desired), but I'm able to replicate the regression using the 1080p file:
iPadOS 14 GM on iPad Pro ~21fps
iOS 12.4.8 on iPhone 6 Plus ~24fps
Quick update, I can also replicate this regression in the current iPadOS 14.2 Beta (18B5052h)
We are seeing this behavior as well and can be reproduced here: https://8w.8thwall.app/ios14-video-perf
I've included videos of this test site running without issue on the older iPhone XS Max running iOS. 13.7 (https://www.youtube.com/watch?v=MLNgYmj-_5s) but drops to half the frame rate on the newer
iPhone 11 running iOS 14.0.1 (https://www.youtube.com/watch?v=L-v0q7iiY7E).
Thanks for the reports and testcases. This performance regression was due to video -> texture teximage2d failing the HW code path and reverting to SW conversion. It is the same root cause as bug 215908.
*** This bug has been marked as a duplicate of bug 215908 ***