Bug 171597 – REGRESSION: WebGL low performance of layer compositing in cross-origin iframe

• Component: Layout and Rendering
• Status: RESOLVED WONTFIX

[Nik S]

High sizes of webgl canvases may cause composing layout performance issues.

Expected behavior:
60 FPS without UI freezing. In other words, performance on par with other browsers (Chrome and Firefox).

Actual behavior:
<15 FPS (roughly) with frequent UI freezing.

Steps to Reproduce:
1. Open http://jsfiddle.net/unlimit/3pwbLfmn/70/embedded/result/ in Safari 10.1 (make sure that you open Safari on built-in Retina display);
2. You can see FPS on the top left corner (33 FPS for my hardware);
3. Click or click-and-dragg on canvas then you can see increase FPS (up to 45 for me);
4. After steps above you can feel low framerate and UI freezing;
5. Press ‘Enable Safari fix` to get rid of UI freezing.

Testing hardware:
MPB, 13”, Early 2015, 2,7 GHz Intel Core i5, 16GB, SSD, Intel Iris Graphics 6100 1536 MB. macOS 10.12.4, Safari 10.1 (12603.1.30.0.34, r216107)

[Alexey Proskuryakov]

On a 15" Mac Book Pro (Mid-2015), I get 60 FPS in shipping Safari/WebKit, and 33 FPS in nightly.

I didn't get UI sluggishness after step 3, but this machine has a much more powerful GPU of course.

[Radar WebKit Bug Importer]

<rdar://problem/31977191>

[Simon Fraser (smfr)]

This started with https://trac.webkit.org/changeset/210372/

[Alexey Proskuryakov]

> This started with https://trac.webkit.org/changeset/210372/

But this doesn't reproduce for me in shipping Safari/WebKit, which should already have this change in.

[Nik S]

(In reply to Alexey Proskuryakov from comment #1)
> On a 15" Mac Book Pro (Mid-2015), I get 60 FPS in shipping Safari/WebKit,
> and 33 FPS in nightly.
> 
> I didn't get UI sluggishness after step 3, but this machine has a much more
> powerful GPU of course.

I've just test demo on 15" MBP Mid 2016 with active integrated GPU (Intel HD Graphics 530) and I couldn't reproduce UI sluggishness. However, it is reproduced for my real application on 15" MBP Mid 2016. Unfortunately I can't share this app so I'll try to prepare another demo for 15" MBP.

[Simon Fraser (smfr)]

I was able to clearly reproduce this on my older MacBook Pro (the first Retina model), and autospade it to r210372.

[Dean Jackson]

This is actually expected behaviour. On some hardware, the integrated card is good enough to run your demo at a nice framerate. On others, it isn't.

If you really need to get maximum performance, you can opt in to using the discrete GPU by using the powerPreference context creation attribute:

https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.2.1

[Alexey Proskuryakov]

I also bisected, and found the r215070 to be the culprit. That matches the symptom of the FPS going up after interacting with the page.

Maybe that's still expected behavior, but it feels questionable to me.

[Nik S]

(In reply to Dean Jackson from comment #7)
> This is actually expected behaviour. On some hardware, the integrated card
> is good enough to run your demo at a nice framerate. On others, it isn't.
> 
> If you really need to get maximum performance, you can opt in to using the
> discrete GPU by using the powerPreference context creation attribute:
> 
> https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.2.1

Thank you for explanation. However, I guess that there is another case. Could you please explain why on the same integrated GPU (Intel Iris Graphics 6100) I can get so different FPS values when safari fix is enabled/disabled? 

In this demo http://jsfiddle.net/unlimit/3pwbLfmn/85/embedded/result/ fix button just add renderer.context.finish(); webgl context finish call.

[Simon Fraser (smfr)]

I think this is a combination of two issues.

The first is that we now throttle rAF in cross-origin iframe to 30fps after http://trac.webkit.org/r215070, and this test case hits that.

The second is that on some hardware, low-power GL performance is much worse than high-power GL performance.

[Nik S]

Thanks for reply.

(In reply to Simon Fraser (smfr) from comment #10)
> I think this is a combination of two issues.
> The first is that we now throttle rAF in cross-origin iframe to 30fps after
> http://trac.webkit.org/r215070, and this test case hits that.

Oh, thanks for information I don't now it. But in my another test without iframe I faced with the same issue and fps was much less than 30.

> The second is that on some hardware, low-power GL performance is much worse
> than high-power GL performance.

I didn't quite understand this point because I tested my demo page on MPB 13" without high-power GPU.

[Alexey Proskuryakov]

> But in my another test without iframe I faced with the same issue and fps was much less than 30.

Could you please make that test available to us? Is that a regression in nightlies too, or can you reproduce in shipping Safari? May be best to file a separate bug about that, as this bug tracks the regression from cross-origin throttling, and is already confusing enough.

[Nik S]

I've created another report with detailed description see https://bugs.webkit.org/show_bug.cgi?id=171924