Bug 223740 – Inconsistent WebGL video upload performance

• Component: WebGL
• Status: NEW

[Kimmo Kinnunen]

Created attachment 424226 [details]
testcase

Reported as per Marcin:
1) Results on my iPhone SE ~ 2017 14.4.1 and iPad Air 2020 14.4.1

   1.1 paused movie 
       - performance 60fps
       - no visual presentation drops

   1.2 playing movie with texture updates at 10FPS
       - performance 60fps
       - HEAVY presentation drops!!!!!!! why?

   1.3 playing movie with texture updates at 60FPS
       - performance 60fps
       - no visual presentation drops (interesting right?)

2) Results on my iMac ~ 2017 Catalina 10.15.7, Safari 14.2 TP 122

   1.1 paused movie 
       - performance 60fps
       - no visual presentation drops

   1.1 playing movie (texture update rate makes no difference here)
       - performance 60fps
       - random visual presentation drops, 
         (intensifies with more pressure on CPU/GPU)

Zip file contains alternate video files (puppets), results with it are much better on iMac but causes same heavy drops on iPhone.

[Marcin]

Thanks Kimmo. 
I would like to make one thing clear, when running test case please observe blinking background, if it blinks consistently with grey-ish color it means we have no presentation drops which is great. If background pops in red or cyan that means at least 1 presentation frame drop have occured.

[Radar WebKit Bug Importer]

<rdar://problem/76096748>

Is there any news to share about this? The Android devices I've tried are still dramatically faster at sampling large video textures than iOS, even with iOS 15.

[Kimmo Kinnunen]

(In reply to andj2223 from comment #3)
> Is there any news to share about this? The Android devices I've tried are
> still dramatically faster at sampling large video textures than iOS, even
> with iOS 15.

Thanks for the report. If you have a simple reproduction feel free to attach it to here or a new bug entry.

After some more testing, I found I'm only able to repro texImage2D performance issues when using a webrtc based remote stream. Note: I don't mean a getUserMedia() based video, it's video stream from a remote webrtc peer. But I presume similar codepaths are used for both local and remote streams.

I found several issues citing performance issues with texImage2D and webrtc based video, including some work to enable a GPU->GPU path for dealing with this form of video in shaders, rather than a CPU based readback. I'm really hopeful this will improve matters, and plan to try out 15.1 beta 3 when it becomes available. Let me know if I've misunderstood. I'd rather not spend time building minimal testcases involving remote streams, as they're a bit harder to build than standard video testcases, but I'm willing to put in the time if this recent work doesn't improve things.

Related issues:
https://bugs.webkit.org/show_bug.cgi?id=231031
https://bugs.webkit.org/show_bug.cgi?id=230617
(and several others linked from those)

Also, patch implementing GPU codepath for media streams (goes in on 15.1 beta3?)
https://bugs.webkit.org/attachment.cgi?id=439150&action=diff

[Marcin]

I've just retested provided test case on iPadOS 15 (A14 air pad).
I'm observing massive performance drop. Previously I was using iPadOS 14.x.

[Dustin Kerstein]

I think this is related to https://bugs.webkit.org/show_bug.cgi?id=216250

[Dustin Kerstein]

(In reply to Dustin Kerstein from comment #7)
> I think this is related to https://bugs.webkit.org/show_bug.cgi?id=216250

Sorry, looks like you already knew that (and sorry for the spam).

[Dustin Kerstein]

FYI this and 231031 may be dupes / related. It might also be worth looking into the Feedback assistant bugs: 

FB9688897
FB9666426
FB9554184

See here for another simple replication test case - https://jsfiddle.net/qz9ka6xm (using RGBA textures from a very simple cycling color video).

On stock Safari 15 + latest Beta 15.1 Safari + Safari Technical Preview, when using my 2018 Macbook Pro i9 I am always seeing around 18-20fps in that above test, regardless of enabling GPU Process WebGL and/or WebGL Metal (Chrome and Firefox are >50fps)

However, on a Macbook Air M1, enabling WebGL Metal on Safari 15, seems to fix the issue entirely, with fps >50. When WebGL Metal is disabled (ie. the default setting), I see 4fps...

Has there been any work / investigation into these serious performance regressions? I'm sure this is fairly widespread amongst production websites using WebGL and will only grow as more people upgrade to Safari 15.x

[Kimmo Kinnunen]

(In reply to Dustin Kerstein from comment #9)
> However, on a Macbook Air M1, enabling WebGL Metal on Safari 15, seems to
> fix the issue entirely, with fps >50. When WebGL Metal is disabled (ie. the
> default setting), I see 4fps...

Thank you for the report. I filed this as bug 232235. If you have time, please confirm  the OS version you are seeing the issue.

[Dustin Kerstein]

(In reply to Kimmo Kinnunen from comment #10)
> Thank you for the report. I filed this as bug 232235. If you have time,
> please confirm  the OS version you are seeing the issue.


Thanks Kimmo. That was run on Big Sur 11.6.

Also, do you feel that the existing bug tickets cover the performance regression on Intel Macs, or should we create a new ticket? My MacBook Pro + older Safari used to be able to hit 50+ fps on that test consistently, and now it's ~20fps regardless of enabling GPU Process WebGL and/or WebGL Metal.

[Kimmo Kinnunen]

(In reply to Dustin Kerstein from comment #11)
> Also, do you feel that the existing bug tickets cover the performance
> regression on Intel Macs, or should we create a new ticket? My MacBook Pro +
> older Safari used to be able to hit 50+ fps on that test consistently, and
> now it's ~20fps regardless of enabling GPU Process WebGL and/or WebGL Metal.

Sorry, did not understand this one fully.
Yes, filed this as bug 232296, thanks!