[v 0.10] Gst::init() is slow

[José Alburquerque]

On Sun, 2012-09-09 at 07:31 -0400, José Alburquerque wrote:
> On Sun, 2012-09-09 at 07:01 -0400, José Alburquerque wrote:
> > On Sep 9, 2012, at 4:19 AM, José Alburquerque <jaalburquerque at cox.net> wrote:
> > 
> > > On Sun, 2012-09-09 at 09:46 +0300, Jiergir Ogoerg wrote:
> > >> Thanks,
> > >> To my desktop app startup time is critical, so, if I switch to the Gst
> > >> C interface do you think the gst_init() would never take longer than
> > >> say 200 milliseconds? Or is it nonetheless possible for it to take
> > >> much longer like over 1-2 seconds in some cases?
> > > 
> > > Actually, I think I spoke too soon in my last post.
> > > 
> > > I was just thinking things through more thoroughly and since plug-in
> > > types are not accessible in C.  It may be possible to register the
> > > wrapping functions for these plug-in types later (when they are
> > > constructed) and not at startup (in Gst::init()) since it is not
> > > possible to have these plug-in types from some C code and then try to
> > > wrap them in a C++ wrapper which is why we go through the process of
> > > loading the plug-ins and registering the wrapping functions in the first
> > > place.  It may not even be necessary to register wrapping functions for
> > > these plug-in types.
> > 
> > Sorry, I'm just wrong here.  Though the C types are not available, having one from C code is possible because the plug-ins are created using the GType system.  Registering the wrapping functions for plug-ins is thus still vital upon initialization.
> > 
> > You're better off using C.  I hope I didn't give you false hopes.
> 
> Okay.  I'm going back and forth because the issue is more complicated
> than what I thought.  Could you please ignore this last post.  I'll look
> at this during the week and not rush.  If it's possible it will be in
> the release.  If not it wont.  Sorry.

I believe I've found a possible work around to get this working but it
took longer than I expected to make some patches.  I've filed a bug with
the patches:

https://bugzilla.gnome.org/show_bug.cgi?id=684006

But I'll hold the release off till next week to see if this can be
included.  Sorry for any inconveniences.

> 
> > 
> > -Jose
> > 
> > > 
> > > If the above is so, startup time (Gst::init()) will probably never be
> > > more than the 100ms you mentioned.
> > > 
> > > I'll be looking into this this week at the end of which a new release
> > > should be out.  If it this is doable, I'll include it in that release.
> > > 
> > > In the meanwhile, however, I'm sure that using C will never have such a
> > > slow start-up time.  gst_init() does not load all the possible plug-ins
> > > as gstreamermm does right now.
> > >> 
> > >> 
> > >> On Sun, Sep 9, 2012 at 7:37 AM, José Alburquerque
> > >> <jaalburquerque at cox.net> wrote:
> > >>       On Sat, 2012-09-08 at 13:19 +0300, Jiergir Ogoerg wrote:
> > >>> Hi,
> > >>> Gst::init() takes like 100+ ms, on rare occasions it takes
> > >>       even
> > >>> longer, like over 2-4 seconds. Is it normal?
> > >> 
> > >> 
> > >>       Probably.  The reason is that Gst::init() not only initializes
> > >>       GStreamer, it also initializes glibmm (which it relies on) and
> > >>       registers
> > >>       methods that wrap C types to correct C++ types for all the
> > >>       GStreamer
> > >>       GObject and GstMiniObject derived types and all the GStreamer
> > >>       plug-in
> > >>       types that gstreamermm makes available to be used in a C++
> > >>       way.  In the
> > >>       process, it must load all the plug-ins that gstreamermm makes
> > >>       available
> > >>       (this is probably the most time consuming part though only for
> > >>       the
> > >>       execution for which the plug-ins have not been loaded; the
> > >>       rest of the
> > >>       executions wont experience so much a delay).  We know of no
> > >>       other way to
> > >>       ensure that the C objects handled are correctly differentiated
> > >>       and
> > >>       treated as appropriate C++ classes.
> > >> 
> > >>> 
> > >>> To combat this I do Gst::init() in another pthread for my
> > >>       gui app to
> > >>> show up instantly as usually.
> > >>> 
> > >>> Using Ubuntu 12.04 amd64.
> > >>> Intel Core i5.
> > >> 
> > >>> _______________________________________________
> > >>> gstreamer-devel mailing list
> > >>> gstreamer-devel at lists.freedesktop.org
> > >>> 
> > >>       http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > >> 
> > >> 
> > >>       --
> > >>       José
> > >> 
> > >>       _______________________________________________
> > >>       gstreamer-devel mailing list
> > >>       gstreamer-devel at lists.freedesktop.org
> > >>       http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > >> 
> > >> 
> > >> _______________________________________________
> > >> gstreamer-devel mailing list
> > >> gstreamer-devel at lists.freedesktop.org
> > >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > > 
> > > -- 
> > > José
> > > 
> > > _______________________________________________
> > > gstreamer-devel mailing list
> > > gstreamer-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> > 
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 

-- 
José