MobileSafari was constantly using 10-15% CPU viewing a PDF
authortimothy_horton@apple.com <timothy_horton@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 29 Jun 2017 04:37:53 +0000 (04:37 +0000)
committertimothy_horton@apple.com <timothy_horton@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 29 Jun 2017 04:37:53 +0000 (04:37 +0000)
commit7958af822b427c6427d4b6065140507335492583
tree18cf1d32413de6b58628651b7564ff69ed80cc78
parentb5d845494c43c21746e94b4a2f85a2383001b185
MobileSafari was constantly using 10-15% CPU viewing a PDF
https://bugs.webkit.org/show_bug.cgi?id=173944
<rdar://problem/33039910>

Reviewed by Simon Fraser.

Source/WebKit2:

* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _doAfterNextStablePresentationUpdate:]):
(-[WKWebView _doAfterNextPresentationUpdate:]):
(-[WKWebView _doAfterNextPresentationUpdateWithoutWaitingForPainting:]):
Bail early and just dispatch_async the completion block if we are using a custom
content view; these methods are very specific to the implementation of WKContentView
and don't make sense with custom content views.

doAfterNextStablePresentationUpdate is particularly egregious because, since
we will never call the stable update callbacks (because we bail from didCommitLayerTree
if we aren't using WKContentView), it will keep calling doAfterNextPresentationUpdate
over and over again.

Tools:

* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WebKit2Cocoa/WKPDFViewStablePresentationUpdateCallback.mm:
Add a test that we ever call the stable presentation update callback
when we have a WKPDFView up, instead of infinitely looping.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@218917 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit2/ChangeLog
Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm
Tools/ChangeLog
Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
Tools/TestWebKitAPI/Tests/WebKit2Cocoa/WKPDFViewStablePresentationUpdateCallback.mm [new file with mode: 0644]