[MSE] Seeking or entering fullscreen can cause extreme CPU usage
authorjer.noble@apple.com <jer.noble@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 17 Jun 2017 02:20:02 +0000 (02:20 +0000)
committerjer.noble@apple.com <jer.noble@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 17 Jun 2017 02:20:02 +0000 (02:20 +0000)
https://bugs.webkit.org/show_bug.cgi?id=173505

Reviewed by Tim Horton.

When support for painting MSE to WebGL was added in r217185, the implementation of
SourceBufferPrivateAVFObjC::isReadyForMoreSamples() was modified to support asking
the decompression session if it was ready. That change, however, caused an extreme
performance regression in the normal playback path, where WebKit will effectively
append samples endlessly to the AVSampleBufferDisplayLayer, which admirably enqueued
each of them for decoding. Eventually, the cost of iterating over the CMBufferQueue
overwhelmed the cost of decoding, and caused the extreme lag seen when seeking.

Make sure to property query the AVSampleBufferDisplayLayer for isReadyForMoreMediaData
before enqueuing.

* platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
(WebCore::SourceBufferPrivateAVFObjC::isReadyForMoreSamples):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@218438 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Source/WebCore/ChangeLog
Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm

index dea32cc..56678d7 100644 (file)
@@ -1,3 +1,24 @@
+2017-06-16  Jer Noble  <jer.noble@apple.com>
+
+        [MSE] Seeking or entering fullscreen can cause extreme CPU usage
+        https://bugs.webkit.org/show_bug.cgi?id=173505
+
+        Reviewed by Tim Horton.
+
+        When support for painting MSE to WebGL was added in r217185, the implementation of
+        SourceBufferPrivateAVFObjC::isReadyForMoreSamples() was modified to support asking
+        the decompression session if it was ready. That change, however, caused an extreme
+        performance regression in the normal playback path, where WebKit will effectively
+        append samples endlessly to the AVSampleBufferDisplayLayer, which admirably enqueued
+        each of them for decoding. Eventually, the cost of iterating over the CMBufferQueue
+        overwhelmed the cost of decoding, and caused the extreme lag seen when seeking.
+
+        Make sure to property query the AVSampleBufferDisplayLayer for isReadyForMoreMediaData
+        before enqueuing.
+
+        * platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
+        (WebCore::SourceBufferPrivateAVFObjC::isReadyForMoreSamples):
+
 2017-06-16  Sam Weinig  <sam@webkit.org>
 
         [WebIDL] Remove custom bindings for HTMLDocument
index 30082b7..898dd27 100644 (file)
@@ -1002,8 +1002,12 @@ void SourceBufferPrivateAVFObjC::bufferWasConsumed()
 bool SourceBufferPrivateAVFObjC::isReadyForMoreSamples(const AtomicString& trackIDString)
 {
     int trackID = trackIDString.toInt();
-    if (trackID == m_enabledVideoTrackID)
-        return !m_decompressionSession || m_decompressionSession->isReadyForMoreMediaData();
+    if (trackID == m_enabledVideoTrackID) {
+        if (m_decompressionSession)
+            return m_decompressionSession->isReadyForMoreMediaData();
+
+        return [m_displayLayer isReadyForMoreMediaData];
+    }
 
     if (m_audioRenderers.contains(trackID))
         return [m_audioRenderers.get(trackID) isReadyForMoreMediaData];