From: Stefan Kost <ensonic@users.sf.net>
Date: Sat, 22 May 2010 19:33:09 +0000 (+0300)
Subject: design: more planning on lazy caps.
X-Git-Tag: RELEASE-0.10.30~165
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=29231bb963cead68e82d61b8e5be723c073d1c49;p=platform%2Fupstream%2Fgstreamer.git

design: more planning on lazy caps.
---

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