[Webkit-unassigned] [Bug 150392] [GTK] Implement rendering frames timeline panel for GTK+ port

[bugzilla-daemon at webkit.org]

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

--- Comment #7 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #5)
> (In reply to comment #0)
> > The mac implementation is based on RunLoopObserver, that only has
> > an implementation based on CF. It's not currently possible to do the same
> > with the glib main loop, so even if there's a proper platform abstraction of
> > RunLoopObserver, we won't be able to provide a glib implementation. Maybe
> > when persistent sources patch lands (see bug #138691), we can provide a way
> > to monitor our sources.
> 
> If you could provide some rationale for why RunLoopObserver isn't a
> sufficient abstraction in <https://bugs.webkit.org/show_bug.cgi?id=142748>,
> that would be helpful in moving that discussion forward.

Yes, the glib main loop doesn't provide any way to know its status, and there isn't any GMainLoopObserver in glib either. We could implement something like that in glib, though, but in the meantime we need a different way to implement at least the rendering frames panel. What we can do with the current glib main loop, is to use custom sources, that we can dispatch. That way we can do whatever before and after the source is actually dispatched, which is what I'm doing in this patch. We plan to change some glib sources used in WebKit with custom sources like the one I'm using in this patch, but in a more generic way. Once we have that we could implement a RunLoopObserver, but only to monitor our own custom sources.

-- 
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/20151022/cb661a2e/attachment.html>