RunLoop::Timer uses a persistent source making it more efficient.
Created attachment 264472 [details] Patch
This will not build because it depends on patch attached to bug #150754
Comment on attachment 264472 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=264472&action=review > Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:69 > + // We use a GLib timer because otherwise GTK+ event handling during dragging can starve WebCore timers, which have a lower priority. > + // Use a higher priority than WebCore timers. I don’t understand what “we use a GLib timer” means here, since we are using a RunLoop timer. Should be clearer on that. > Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:107 > + static const double targetFramerate = 1 / 60.0; > + // When rendering layers takes more time than the target delay (0.016), we end up scheduling layer flushes > + // immediately. Since the layer flush timer has a higher priority than WebCore timers, these are never > + // fired while we keep scheduling layer flushes immediately. > + double current = monotonicallyIncreasingTime(); > + double timeToNextFlush = std::max(targetFramerate - (current - m_fireTime), 0.0); We prefer use of std::chrono in new code, rather than the "double in seconds" style we wrote in older code. Would be good to return here and move to that.
(In reply to comment #3) > Comment on attachment 264472 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=264472&action=review > > > Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:69 > > + // We use a GLib timer because otherwise GTK+ event handling during dragging can starve WebCore timers, which have a lower priority. > > + // Use a higher priority than WebCore timers. > > I don’t understand what “we use a GLib timer” means here, since we are using > a RunLoop timer. Should be clearer on that. Yes, the fact that the run loop timer implementation uses a glib timer is an implementation detail. I'll reword that. > > Source/WebKit2/WebProcess/WebPage/gtk/LayerTreeHostGtk.cpp:107 > > + static const double targetFramerate = 1 / 60.0; > > + // When rendering layers takes more time than the target delay (0.016), we end up scheduling layer flushes > > + // immediately. Since the layer flush timer has a higher priority than WebCore timers, these are never > > + // fired while we keep scheduling layer flushes immediately. > > + double current = monotonicallyIncreasingTime(); > > + double timeToNextFlush = std::max(targetFramerate - (current - m_fireTime), 0.0); > > We prefer use of std::chrono in new code, rather than the "double in > seconds" style we wrote in older code. Would be good to return here and move > to that. Ok, I'll do it in a different patch
Committed r191854: <http://trac.webkit.org/changeset/191854>