[gstreamer-bugs] [Bug 620460] info: add new REFCOUNT log level and move refcounting there from LOG level

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=620460
  GStreamer | gstreamer (core) | git

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #2 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-06-03 11:41:38 UTC ---
> I don't like this because it's semantically orthogonal to the current log
> levels.

I don't think it is. I'm sure we can bike-shed about this extensively though.


> Also, GST_LEVEL_LOG is exactly meant for refcounting - it's even saying so in
> the docs. So it makes more sense to me to tell people to create debug logs with
> *:4 in the future and make sure the other messages are DEBUG messages.

No, the INFO/DEBUG vs. LOG distinction is very useful in practice. It is also
reasonably well-defined and used fairly consistently in practice (LOG is for
recurring things in streaming threads etc.)

Of course there's nothing *wrong* with putting refcounting info into the LOG
level, but it's not very *useful* in practice. In fact, it's counter-productive
and annoying, since 99% of the times it just adds a lot of noise to the debug
logs, which makes it harder to read and handle.

Additionally, a new log level means that you can output refcounts more
fine-grained in future by using the right debug category for them (EVENT, CAPS,
MINIOBJECT etc.), which makes it slightly easier to debug refcounting issues
when you're unfortunate enough to be in such a position.

We could call the new category SPAM instead of REFCOUNT, but I don't know when
else one would ever want to use that and not LOG (or MEMDUMP), so it seems
better to just call it what it is.

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