GNOME Bugzilla – Bug 712617
Synchronous D-Bus calls when loading the Flickr plugin
Last modified: 2018-09-24 09:23:25 UTC
GNOME Photos is blank for about 3 seconds after it launched on a SSD disk. This is actually slower than Libreoffice.
- Did you have any non-local photo sources added? eg., Flickr. - What happens if you kill and restart the application? Is it still slow?
1. No 2. No change
andreasn: Still an issue in 3.14? Or is this RESOLVED OBSOLETE?
(In reply to André Klapper from comment #3) > andreasn: Still an issue in 3.14? Or is this RESOLVED OBSOLETE? Yes, this is still an issue. I can reproduce it with current master.
With gnome-photos master and grilo-0.2.11, I get this back trace on slow start-ups. $ gstack $(pidof gnome-photos) ... <snipped out noise about other idle threads> ...
+ Trace 235569
Thread 1 (Thread 0x7fd614139a40 (LWP 32470))
So, this boils down to this function call in our application's startup vfunc: grl_registry_load_plugin_by_id (registry, "grl-flickr", &error)
Reassigning to grilo: https://mail.gnome.org/archives/grilo-list/2015-October/msg00002.html
So, adding an asynchronous version for `grl_registry_load_plugin_by_id` and friends seems to be the solution to me here to prevent the consumer apps encountering cases like this. Or, I can change the existing such functions to async ? (but that would break so many things, so not the best approach, I think ?)
*** Bug 731606 has been marked as a duplicate of this bug. ***
Ping. What's the way forward here? Bug 731606 says that it also affects totem at startup. Aside from stalling gnome-photos on startup, the Flickr integration has been completely broken. The helper process that is used to populate the offline cache with Flickr metadata doesn't work because D-Bus calls time out due to this. I wonder if it will be better to let the application create a GrlSource for a given GoaObject instead of grilo trying to enumerate the sources at startup. An application might already have its own list of GoaObjects to deal with functionality beyond Grilo. For example, gnome-documents/photos uses other GNOME SDKs for online accounts like libgdata, libgfbgraph, libzapojit; the applications issue notifications to indicate the status of those accounts - is the metadata being fetched, are credentials for those accounts still valid, etc.. It might also happen that even though there is a Flickr account, the application won't ever need the GrlSource because all the necessary metadata, thumbnails and images are already cached locally. Hence, I think the application is in a better position to know when a particular GrlSource would be needed.
(In reply to Debarshi Ray from comment #9) > Ping. What's the way forward here? > > Bug 731606 says that it also affects totem at startup. > > Aside from stalling gnome-photos on startup, the Flickr integration has been > completely broken. The helper process that is used to populate the offline > cache with Flickr metadata doesn't work because D-Bus calls time out due to > this. > > I wonder if it will be better to let the application create a GrlSource for > a given GoaObject instead of grilo trying to enumerate the sources at > startup. That's what the lua plugin does. There's nothing stopping you from implementing something similar, eg. create the source async'ly after the plugin has been instantiated. No API changes necessary. I'd welcome a Flickr plugin reimplemented in Lua, fwiw, would save us a few headaches.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/grilo/issues/33.