[Webkit-unassigned] [Bug 173094] [GTK] Get rid of custom marshallers of signals

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jun 8 06:33:01 PDT 2017


--- Comment #3 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Adrian Perez from comment #2)
> Comment on attachment 312293 [details]
> Patch
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=312293&action=review
> Informal r+ from me.


> There is a chance that the generic libffi-based marshaller is slower than the
> custom ones, but it should not be much of an issue because other parts of the
> WebKit code (e.g. rendering) have more weight on CPU usage. And it is nice to
> have code getting removed \o/

Yes, I don't think it will be noticeable and we are using generic already in other signals.

> > Source/WebKit2/UIProcess/API/gtk/WebKitBackForwardList.cpp:87
> > +        g_cclosure_marshal_generic,
> You could as well pass “nullptr” here. According to the documentation for
> “g_signal_new()”
> (https://developer.gnome.org/gobject/stable/gobject-Signals.html#g-signal-
> new):
> > If c_marshaller is NULL, g_cclosure_marshal_generic() will be used as the
> > marshaller for this signal.
> And the same goes to the other changed locations. I have no strong opinion
> about whether
> passing “g_cclosure_marshal_generic” or “nullptr” should be preferred, so
> I'd leave it
> up to you.

g_signal_new is already difficult to read with severl 0, nullptr, nullptr. In some cases we even add a comment explaining what the nullptr/0 is. So, I prefer to pass the marshaller for readability.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170608/6343086c/attachment.html>

More information about the webkit-unassigned mailing list