<div dir="ltr">Hi all,<div><br></div><div>While investigating why some applications on our deployed OS were taking a long time to start, but only the first time one among a set was started on a clean user, we determined that GstRegistry was the cause of the delay, as it's generated in the home directory the first time a GStreamer application runs. (We were hitting this through a WebKit dependency, which initializes GStreamer.)</div><div><br></div><div>Would it be possible to ship a static registry together with the OS (i.e. in /usr) instead? My understanding from reading this [1] is that the current implementation will only read from $XDG_CACHE_HOME.</div><div>Of course, when the information in the system cache is out of date (e.g. because a new plugin was installed), another one would be generated in the home directory and that would take precedence when reading it back.</div><div>Finally, it would be possible to add a command to update the system cache from a process that drives the installation of a new plugin (e.g. a package manager), similarly to how the GTK icon cache or fontconfig cache work.</div><div><br></div><div>I'm interested in contributing a patch to fix this, but I want to know if this is the right approach.</div><div><br></div><div>[1] <a href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstRegistry.html">http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstRegistry.html</a></div><div><br></div><div>Thanks,</div><div>Cosimo</div></div>