summaryrefslogtreecommitdiff
path: root/gvc-mixer-card.c
diff options
context:
space:
mode:
authorNiels De Graef <nielsdegraef@gmail.com>2022-05-29 13:47:33 +0200
committerNiels De Graef <nielsdegraef@gmail.com>2022-05-29 13:47:33 +0200
commit838acedd89b7cd4459bd2a049a5efa1e42f1e5fd (patch)
treee61eb79630e1df8874631ebe75f65edc725d2b69 /gvc-mixer-card.c
parent37a7dfcd5094c46abd09528adcb5d5c7040e2b61 (diff)
downloadlibgnome-volume-control-838acedd89b7cd4459bd2a049a5efa1e42f1e5fd.tar.gz
mixer-control: Don't specify default c_marshaller
Apart from being less code, this actually gives us a tiny performance improvement. Up until a few years ago, if you pass `NULL` as the marshaller for a signal, GLib would fall back to `g_cclosure_marshal_generic` which uses libffi to pack/unpack its arguments. One could avoid this by specifying a more specific marshaller which would then be used to immediately pack and unpack into GValues with the correct type. Lately however, as a way of optimizing signal emission (which can be quite expensive), GLib added a possibility to set a `va_marshaller`, which skips the unnecessary GValue packing and unpacking and just uses a valist variant. Since the performance difference is big enough, if the marshaller argument is NULL, `g_signal_new()` will now check for the simple marshallers (return type NONE and a single argument) and set both the generic and the valist marshaller. In other words, less code for us with behind-the-scenes optimizations. In case you also want va_marshallers for more complex signals, you can use `g_signal_set_va_marshaller()`.
Diffstat (limited to 'gvc-mixer-card.c')
0 files changed, 0 insertions, 0 deletions