[gstreamer-bugs] [Bug 604965] Gst.Application.GstResolveType is useless, or just very slow at best

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=604965
  GStreamer | gst-sharp | git

Sebastian Dröge <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1

--- Comment #3 from Sebastian Dröge <slomo at circular-chaos.org> 2009-12-22 09:52:40 UTC ---
(In reply to comment #2)
> Thanks for the explanation.
> 
> Does that mean that it is sufficient to only check gstreamer-sharp.dll for Gst*
> types? Or is this mechanism also used for elements implemented in C#, so other
> assemblies have to be searched as well?
> In any case, all the System.* assemblies can be skipped, because those will
> certainly not contain any of the GObject types. That alone would speed it up, I
> think. I'll prepare a patch and measure the speedup.

Well, you could have your own bindings for GStreamer elements in your
application for example. For elements that are not bound by us or even for
elements that your application ships.

> I noticed that a request to resolve GstBus and GstMessage also went through
> GstResolveType in my app. Is this correct, or is the mchanism only supposed to
> be for elements. It didn't find a matching type though. This looks logical,
> because in the source I can't find a [GTypeName ("GstBus")] anywhere. But for
> these types the whole lookup still takes 400ms, quite a waste of resources.

It's only meant for elements and other plugin features. GstBus and GstMessage
can be resolved by glib-sharp already and I think it's a bug that it calls the
ResolveType stuff although it has a resolution already. Could you investigate?
(I'm on holidays, can't work on this until early January)

> There is also still a bug in that assembly.GetTypes() can raise an Exception.
> I'll include a fix for that in a patch, when I know how to rework
> GstResolveType.

Great, thanks :)

> The only other thing I can think of to speed this up, is some sort of cache. Is
> that something you would think of as fruitfull to persue?

If it really takes that long and no other solution can be found a cache sounds
ok. Let's first try to fix it different though, caching will be complex :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.