From 29231bb963cead68e82d61b8e5be723c073d1c49 Mon Sep 17 00:00:00 2001 From: Stefan Kost Date: Sat, 22 May 2010 22:33:09 +0300 Subject: [PATCH] design: more planning on lazy caps. --- docs/random/ensonic/lazycaps.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/random/ensonic/lazycaps.txt b/docs/random/ensonic/lazycaps.txt index b631472..97faa6e 100644 --- a/docs/random/ensonic/lazycaps.txt +++ b/docs/random/ensonic/lazycaps.txt @@ -8,13 +8,15 @@ these variants of lazy caps: - need user_data (the string/string-array) - need a free_func for the user_data - need a get_structure_func to fill structure slots as needed + - we can more easily make this iterator based too - operations (e.g. intersect) (see [1]). - need user_data (the iterator) - need a free_func for the user_data - need a get_structure_func to fill structure slots as needed We should add PERFORMANCE category logging to methods that cause lazy caps to be -fully evaluated. +fully evaluated. To get maximum speed benefit we need to inspect places that +loop over structures of a caps and turn them into while() loops where possible. We can use GST_CAPS_FLAGS_LAZY to indicate that caps are not fully constructed. Once caps are fully evaluated, we can remove the flag (and call the free_func). -- 2.7.4