[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 #4 from Thibault Saunier <tsaunier at gnome.org> 2014-09-12 08:32:25 UTC ---
(In reply to comment #3)
> 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.

Ah, I see, nice.

> 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.

The hooks would be dispach only for tracers that are connected to the specific
signals only.

-- 
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.