Bug 150756

Summary: [GTK] Use a RunLoop::Timer to schedule rendering frames in accelerated compositing mode
Product: WebKit Reporter: Carlos Garcia Campos <cgarcia>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, zan
Priority: P2 Keywords: Gtk
Version: WebKit Local Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 150754    
Bug Blocks:    
Attachments:
Description Flags
Patch darin: review+

Description Carlos Garcia Campos 2015-10-31 01:16:01 PDT
RunLoop::Timer uses a persistent source making it more efficient.
Comment 1 Carlos Garcia Campos 2015-10-31 01:21:08 PDT
Created attachment 264472 [details]
Patch
Comment 2 Carlos Garcia Campos 2015-10-31 01:21:37 PDT
This will not build because it depends on patch attached to bug #150754
Comment 3 Darin Adler 2015-10-31 14:45:45 PDT
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.
Comment 4 Carlos Garcia Campos 2015-11-01 01:30:56 PST
(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
Comment 5 Carlos Garcia Campos 2015-11-01 01:32:14 PST
Committed r191854: <http://trac.webkit.org/changeset/191854>