GNOME Bugzilla – Bug 757197
pad: Append hooks instead of prepending to call them in the order they were added
Last modified: 2015-11-11 14:06:45 UTC
See commit message
Created attachment 314244 [details] [review] pad: Append hooks instead of prepending to call them in the order they were added
Review of attachment 314244 [details] [review]: Makes sense, is this documented anywhere? I couldn't find any information on the calling order of the probes. It would be nice to mention it in the docs.
First all blocking probes are called, then all others, then all idle probes. Before my patch each group is called in reverse order of how they were added.
Comment on attachment 314244 [details] [review] pad: Append hooks instead of prepending to call them in the order they were added commit 2dfa548f3645844082c3db65d96d87255701b3ad Author: Sebastian Dröge <sebastian@centricular.com> Date: Tue Oct 27 18:05:05 2015 +0200 pad: Append hooks instead of prepending to call them in the order they were added https://bugzilla.gnome.org/show_bug.cgi?id=757197
commit 1493f4a334f45446b3e81646b7db02c17afc2064 Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed Oct 28 13:04:25 2015 +0200 pad: Document the order in which pad probes are called https://bugzilla.gnome.org/show_bug.cgi?id=757197
Created attachment 315259 [details] [review] pad: test for checking the order of the probe calls
I am uploading a test to verify this feature change. I think that is really important do tests with this kind of changes, even more if the tests are easy to do ;).
Attachment 315259 [details] pushed as b09e959 - pad: test for checking the order of the probe calls
Thanks, I agree that we should test such things :) Did it cause any problems for you, or help with anything you're doing?
Yes, it did because in some places we have more than one probe in the same pad. The specific case is that we have 2 utilities based on probes: 1 - Probe that drops buffers until a keyframe is detected. Then it is removed. 2 - Probe that marks the first buffer that passes through the pad. Then it is removed. If both are used in the same pad, we can suffer this: the (2) utility marks the first buffer and is removed, but the (1) one drops the buffer because it is not a keyframe, so we loss the mark of the first buffer. I know that this can be fixed using an unique probe for both things, but we already have this utilities implemented in this ways.