[Bug 733187] integrating the tracer branch

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=733187
  GStreamer | gstreamer (core) | 1.x

--- Comment #3 from Stefan Sauer (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2014-09-12 08:28:38 UTC ---
Thanks for taking a look!

1) I started with GstStructures to pass all the arguments and that turned out
to cause quite a bit of overhead and the valist looked much simpler. On the
other hand, using a GstStructure would make it much easier to provide extra
fields in an extensible way. But thanks for pointing out that this would be an
issue for introspection.

I like the signal idea and will think about it. So the baseclass will implement
the hook signal and trigger it instead of calling dispatch. As the signal
supports GQuark detail - that could be a way to extend the hooks - right now I
am not happy about the GstTracerMessageId/GstTracerHookId as they are static
enums.

2) The GstTracer:params is for passing parameters to the tracer. You can set
flags when specifying the tracers: GST_TRACE="log(events,buffers);stats(all)"
and in this case 'stats' would receive 'all' on the params proeprty.

3) The GstTracer:masks property is set by each tracer instance to tell what it
wants to be invoked for. This is probably going away if we use the signal
method you propose. Allthough then the hooks would be all dispatched to all
tracers and they must quickly return for those that they don't care about.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.