[Webkit-unassigned] [Bug 150756] [GTK] Use a RunLoop::Timer to schedule rendering frames in accelerated compositing mode

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Oct 31 14:45:45 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=150756

Darin Adler <darin at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #264472|review?                     |review+
              Flags|                            |

--- Comment #3 from Darin Adler <darin at apple.com> ---
Comment on attachment 264472
  --> https://bugs.webkit.org/attachment.cgi?id=264472
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151031/931f52f3/attachment-0001.html>


More information about the webkit-unassigned mailing list