[Webkit-unassigned] [Bug 226841] Serious WebGL/Metal performance regression in Safari Technology Preview

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=226841

--- Comment #5 from Kimmo Kinnunen <kkinnunen at apple.com> ---
So there are two problems:
1) When UI is running slow, compositor might skip the frame and we will reuse the back  buffer but not cancel the work. The work on that back buffer might still be executing, in case the UI slowness is due to slow WebGL content. Drawing a new slow frame on top of this is only making it slower.

2) Regardless or in conjunction to to 1), there is the problem of not waiting on a fence for completing certain amount of frames (2-3?).

Discussed in passing in bug 222731 but I didn't file a specific bug about the work yet (we can use this bug).


I'd imagine conceptually we could fix 1) by implementing glDiscardFramebuffer() and call that first thing for the new frame in case of preserveDrawingBuffer=false, but I don't know how effective would that be.

Other would be to make sure sync points work and add a sync point per frame and wait for the  i-2 sync point?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210610/3e980d45/attachment.htm>