RESOLVED FIXED 198367
REGRESSION(r244182): [GTK] Web view no longer updated after re-entering AC mode 
https://bugs.webkit.org/show_bug.cgi?id=198367
Summary REGRESSION(r244182): [GTK] Web view no longer updated after re-entering AC mode
Carlos Garcia Campos
Reported 2019-05-30 03:21:18 PDT
This happens because we leave accelerated compositing mode when a rendering update is scheduled in RenderingUpdateScheduler. The threaded compositor display refresh monitor is destroyed without completing the frame, so that the RenderingUpdateScheduler is left scheduled forever, ignoring any new schedule request. We need to ensure we complete the frame request before destrying the display refresh monitor to leave the RenderingUpdateScheduler in a consistent state.
Attachments
Patch (2.09 KB, patch)
2019-05-30 03:24 PDT, Carlos Garcia Campos 		svillar: review+
ews-watchlist: commit-queue-
DetailsFormatted DiffDiff
Archive of layout-test-results from ews104 for mac-highsierra-wk2 (2.77 MB, application/zip)
2019-05-30 18:12 PDT, EWS Watchlist 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Carlos Garcia Campos
Comment 1 2019-05-30 03:24:04 PDT
Created attachment 370932 [details] Patch
Sergio Villar Senin
Comment 2 2019-05-30 03:44:56 PDT
Comment on attachment 370932 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=370932&action=review Nice catch! > Source/WebKit/ChangeLog:9 > + RenderingUpdateScheduler. The threaded compositor display refresh monitor is destroyed without completing the Mind replacing "threaded compositor display refresh monitor" by ThreadedDisplayRefreshMonitor ? The former is a bit difficult to read. > Source/WebKit/ChangeLog:11 > + need to ensure we complete the frame request before destrying the display refresh monitor to leave the Nit: destrying -> destroying > Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedDisplayRefreshMonitor.cpp:94 > + DisplayRefreshMonitor::handleDisplayRefreshedNotificationOnMainThread(this); Looks like DisplayReferehMonitor already protects client notifications so it should be safe to call this even when the object is about to be destroyed. Could you confirm that?
Carlos Garcia Campos
Comment 3 2019-05-30 04:05:17 PDT
(In reply to Sergio Villar Senin from comment #2) > Comment on attachment 370932 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=370932&action=review > > Nice catch! Thanks. > > Source/WebKit/ChangeLog:9 > > + RenderingUpdateScheduler. The threaded compositor display refresh monitor is destroyed without completing the > > Mind replacing "threaded compositor display refresh monitor" by > ThreadedDisplayRefreshMonitor ? The former is a bit difficult to read. Sure. > > Source/WebKit/ChangeLog:11 > > + need to ensure we complete the frame request before destrying the display refresh monitor to leave the > > Nit: destrying -> destroying Oops > > Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedDisplayRefreshMonitor.cpp:94 > > + DisplayRefreshMonitor::handleDisplayRefreshedNotificationOnMainThread(this); > > Looks like DisplayReferehMonitor already protects client notifications so it > should be safe to call this even when the object is about to be destroyed. > Could you confirm that? That's right.
EWS Watchlist
Comment 4 2019-05-30 18:12:01 PDT
Comment on attachment 370932 [details] Patch Attachment 370932 [details] did not pass mac-wk2-ews (mac-wk2): Output: https://webkit-queues.webkit.org/results/12333587 New failing tests: http/wpt/service-workers/useragent.https.html
EWS Watchlist
Comment 5 2019-05-30 18:12:03 PDT
Created attachment 371008 [details] Archive of layout-test-results from ews104 for mac-highsierra-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-highsierra-wk2 Platform: Mac OS X 10.13.6
Carlos Garcia Campos
Comment 6 2019-05-31 01:12:52 PDT
Committed r245954: <https://trac.webkit.org/changeset/245954>
Note You need to log in before you can comment on or make changes to this bug.