[cheese] Updated TODO

[Yuvaraj Pandian <yuvipanda src gnome org>]

commit ac7cdc22c5ea85c8cfa9a1e142ff38615bc4c763
Author: Yuvaraj Pandian T <yuvipanda gmail com>
Date:   Sun Aug 8 20:55:35 2010 +0530

    Updated TODO

 TODO |   44 +-------------------------------------------
 1 files changed, 1 insertions(+), 43 deletions(-)
---
diff --git a/TODO b/TODO
index 4d6bf74..6c8ac1c 100644
--- a/TODO
+++ b/TODO
@@ -4,47 +4,5 @@ please fix me before 3.0
   changing effects, loading webcam, starting recording video
 8 drop mx table layout
   * add a 1px white border around previews
-7 while the webcam is loading, do not allow to take a picture, access
-  preferences etc.
 7 improve video recording
-6 merge gsettings branch on master
-5 remove all warnings when compiling
-5 remove runtime warnings
-? move to gapplication
-? move to gtk3
-
-NOTES, particularly about "show a throbber" and startup time
-
-Who's taking so much time at cheese startup?
-- cheese_camera_connect_effect_texture
-
-That's the most expensive thing we do, it takes a rough 50% (maybe more)
-of startup time, particularly link_many for each effect is quite
-expensive because it has to match colorspace caps (but in general, gst
-linking is slow).
-
-Can it be avoided? I doubt so[1]. Can it be postponed? definitely.
-
-There's no reason to link all the effects at startup, the
-highest priority thing at startup is show the window and put an image
-into it (or if the camera preview takes some time to show up at least
-show something moving like a throbber as we always did).  The effects
-section of the pipeline can be isolated with a valve,
-meanwhile the main pipeline can be started, when the effects are ready
-we can connect them. Ideally given they all have a valve we could
-connect them one at the time and show a throbber for each one. So when
-the user clicks on effect he can see that they are progressively
-loading (or if it clicks on effects when they are ready he won't notice
-the loading thing at all).
-
-Obviously all this stuff has to be done async so that the UI doesn't
-ever block waiting for each task to complete. This could be done with a
-separate thread like we did or taking advantage of gstreamer async
-facilities (GstBus, GstMessages) or, probably, with a mix of the two.
-
-1. gst_element_link_many is quite slow, a good amount of performance can
-be gained using _link_pads or _link_pads_full.
-The latter, from 0.10.30, can avoid checking if the elements are in the
-same bin if we already know they are (and we know it, we just called
-add_many) or it can avoid caps matching checks if we already know that
-caps are compatible.
+6 merge gsettings branch on master
\ No newline at end of file