Title: [198745] trunk/Source/WebCore
- Revision
- 198745
- Author
- simon.fra...@apple.com
- Date
- 2016-03-28 10:17:51 -0700 (Mon, 28 Mar 2016)
Log Message
Inspector Memory Timeline sometimes encounters unstoppable rAF drawing
https://bugs.webkit.org/show_bug.cgi?id=155906
Reviewed by Anders Carlsson.
It was possible to get Web Inspector into a state where repeated, expensive
requestAnimationFrame calls prevented user events from being handled, making it
unresponsive.
requestAnimationFrame uses callOnMainThread() to get a notification from the
CVDispayLink thread to the main thread, which is a -performSelectorOnMainThread...
Under the hood, this ends up as a CFRunLoopPerformBlock().
User events come in via Connection::enqueueIncomingMessage(), which uses RunLoop::main()::dispatch(),
which uses a CFRunLoopSource. Evidently, repeated calls to CFRunLoopPerformBlock() can prevent the
CFRunLoopSource from being handled.
Fix by moving requestAnimationFrame from callOnMainThread() to RunLoop::main()::dispatch().
* platform/graphics/mac/DisplayRefreshMonitorMac.cpp:
(WebCore::DisplayRefreshMonitorMac::displayLinkFired):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (198744 => 198745)
--- trunk/Source/WebCore/ChangeLog 2016-03-28 17:15:50 UTC (rev 198744)
+++ trunk/Source/WebCore/ChangeLog 2016-03-28 17:17:51 UTC (rev 198745)
@@ -1,3 +1,27 @@
+2016-03-25 Simon Fraser <simon.fra...@apple.com>
+
+ Inspector Memory Timeline sometimes encounters unstoppable rAF drawing
+ https://bugs.webkit.org/show_bug.cgi?id=155906
+
+ Reviewed by Anders Carlsson.
+
+ It was possible to get Web Inspector into a state where repeated, expensive
+ requestAnimationFrame calls prevented user events from being handled, making it
+ unresponsive.
+
+ requestAnimationFrame uses callOnMainThread() to get a notification from the
+ CVDispayLink thread to the main thread, which is a -performSelectorOnMainThread...
+ Under the hood, this ends up as a CFRunLoopPerformBlock().
+
+ User events come in via Connection::enqueueIncomingMessage(), which uses RunLoop::main()::dispatch(),
+ which uses a CFRunLoopSource. Evidently, repeated calls to CFRunLoopPerformBlock() can prevent the
+ CFRunLoopSource from being handled.
+
+ Fix by moving requestAnimationFrame from callOnMainThread() to RunLoop::main()::dispatch().
+
+ * platform/graphics/mac/DisplayRefreshMonitorMac.cpp:
+ (WebCore::DisplayRefreshMonitorMac::displayLinkFired):
+
2016-03-28 Chris Dumez <cdu...@apple.com>
Disk cache speculative validation requests do not have the 'Referer' HTTP header set
Modified: trunk/Source/WebCore/platform/graphics/mac/DisplayRefreshMonitorMac.cpp (198744 => 198745)
--- trunk/Source/WebCore/platform/graphics/mac/DisplayRefreshMonitorMac.cpp 2016-03-28 17:15:50 UTC (rev 198744)
+++ trunk/Source/WebCore/platform/graphics/mac/DisplayRefreshMonitorMac.cpp 2016-03-28 17:17:51 UTC (rev 198745)
@@ -30,7 +30,7 @@
#include <QuartzCore/QuartzCore.h>
#include <wtf/CurrentTime.h>
-#include <wtf/MainThread.h>
+#include <wtf/RunLoop.h>
namespace WebCore {
@@ -103,7 +103,7 @@
auto weakPtr = m_weakFactory.createWeakPtr();
- callOnMainThread([weakPtr] {
+ RunLoop::main().dispatch([weakPtr] {
if (auto* monitor = weakPtr.get())
handleDisplayRefreshedNotificationOnMainThread(monitor);
});
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
