I've tried this on Fedora 26 Beta Live in VM and it seems there is a lag sometimes when opening Users panel, but not sure that this is exactly the same what Allan described...

It is "slowly" printing the following message many times for various locales during the opening:
(gnome-control-center:347): GnomeDesktop-DEBUG: Ignoring '...' as a locale, since it lacks translations

So it might be Big 744477, or something similar...

Allan, can you confirm that it is printing the mentioned messages during opening?

It is worth testing it under sysprof.

Created attachment 353940 [details]
profiling of opening of user-accounts

for me user-accounts panel take 12 seconds to open.

Created attachment 353941 [details]
out of strace

The strace shows a lot of calls like this
ioctl(21, VIDIOC_ENUM_FRAMEINTERVALS, {index=0, pixel_format=v4l2_fourcc('M', 'J', 'P', 'G'), width=800, height=600, type=V4L2_FRMIVAL_TYPE_DISCRETE, discrete=1/30}) = 0
ioctl(21, VIDIOC_ENUM_FRAMEINTERVALS, {index=1, pixel_format=v4l2_fourcc('M', 'J', 'P', 'G'), width=800, height=600, type=V4L2_FRMIVAL_TYPE_DISCRETE, discrete=1/25}) = 0
ioctl(21, VIDIOC_ENUM_FRAMEINTERVALS, {index=2, pixel_format=v4l2_fourcc('M', 'J', 'P', 'G'), width=800, height=600, type=V4L2_FRMIVAL_TYPE_DISCRETE, discrete=1/20}) = 0
ioctl(21, VIDIOC_ENUM_FRAMEINTERVALS, {index=3, pixel_format=v4l2_fourcc('M', 'J', 'P', 'G'), width=800, height=600, type=V4L2_FRMIVAL_TYPE_DISCRETE, discrete=1/15}) = 0
ioctl(21, VIDIOC_ENUM_FRAMEINTERVALS, {index=4, pixel_format=v4l2_fourcc('M', 'J', 'P', 'G'), width=800, height=600, type=V4L2_FRMIVAL_TYPE_DISCRETE, discrete=1/10}) = 0

The strace covers 15 seconds, where 3 seconds are probably normal load and 12 seconds is v4l2-related only...

I am not really familiar with sysproof, but it seems similar, there are 12 seconds with only v4l2-related and 80211-related stuff. 80211 is for wifi, so it should be irrelevant to user-accounts.

v4l2 is for camera/video. It may be probably somehow loaded as a part of photo dialog. Bastien, don't you have an idea?

Have you tried also other panels? Does it affect only user-accounts panel?

(In reply to Ondrej Holy from comment #6)
> The strace covers 15 seconds, where 3 seconds are probably normal load and
> 12 seconds is v4l2-related only...
> 
> I am not really familiar with sysproof, but it seems similar, there are 12
> seconds with only v4l2-related and 80211-related stuff. 80211 is for wifi,
> so it should be irrelevant to user-accounts.
> 
> v4l2 is for camera/video. It may be probably somehow loaded as a part of
> photo dialog. Bastien, don't you have an idea?

Easiest would be to see if the cheese test app does the same. Was compiled as tests/cheese-test-chooser last time I looked at this, which I haven't in a couple of years.

(In reply to Ondrej Holy from comment #7)
> Have you tried also other panels? Does it affect only user-accounts panel?

Yes, Yes

Baptiste, can you please try the cheese-test-chooser mentioned by Bastien? You have to build the cheese from source. If you don't know how to do it, it may be enough to try cheese itself first... do you also see slow startup? does strace output also contain continuous v4l2-related output?

Allan, can you please check that you also see the continuous v4l2-related output from strace when starting user-accounts?

I wonder that I don't see anything v4l2-related in my case, however, I can't also reproduce such hangs on startup... it has to be hardware dependent.

Created attachment 354236 [details]
strace output

(In reply to Ondrej Holy from comment #11)
> Allan, can you please check that you also see the continuous v4l2-related
> output from strace when starting user-accounts?

That does appear in strace output, yes.

Thanks. So you also see v4l2-related output, interesting. Your log covers 26 seconds, because you started strace with just gnome-control-center without user-accounts parameter. So, 14 seconds probably covers a load of gnome-control-center and consequent activation of the user-accounts panel. Then, there are 5 seconds of v4l2-related output. You told about 3 seconds delay initially, so it might be 5 seconds this time...

Can you please somebody try cheese as mentioned in Comment 10? What is your version of cheese? Can you please try to downgrade it?

Sounds like a duplicate of Bug 782627 for cheese.

(In reply to Ondrej Holy from comment #15)
> Can you please somebody try cheese as mentioned in Comment 10? What is your
> version of cheese? Can you please try to downgrade it?

It might be also a bug in kernel if that doesn't help...

Hello,

I can confirm bug 782627 is related to this one, because I have the same problem described, and once I have unplugged my webcam, both cheese and user-accounts start immediately.

Let's mark this as a duplicate of the cheese bug for now, because gnome-control-center builds on libcheese. Please see my comment there and provide more info if possible. We have to figure out if it is cheese bug, or kernel bug. Some workaround for g-c-c will be probably needed if it can't be fixed easily in cheese...

*** This bug has been marked as a duplicate of bug 782627 ***

Created attachment 361964 [details] [review]
user-accounts: Prevent freeze caused by external cameras

cheese_camera_device_monitor_new freezes the whole panel when opening
for a couple of seconds if external camera is connected. This is not
acceptable. Probably it is bug in kernel. Let's run this on a thread
as a workaround before it is fixed on the right place.

Created attachment 361965 [details] [review]
user-accounts: Show spinner before camera monitor creation

It may take some time before cheese_camera_device_monitor_new finishes.
Let's show the spinner to be obvious that something is happening.

I think that it is not acceptable that opening of users panel takes such a long time. I don't know what's exactly wrong and how to fix it. So I am proposing at least a workaround for Settings. What do you think? Unfortunately, my external webcam seems broken, so the patches are untested. Can somebody test it?

Review of attachment 361964 [details] [review]:

Thank you!

I guess running it in a gtask is an acceptable workaround.

Being "cancellable" doesn't seem really necessary, but no problems here.

Review of attachment 361965 [details] [review]:

Thanks!

Lets land this also in the gnome-3-26 in the hopes we can include it in 3.26.2.

(In reply to Ondrej Holy from comment #21)
> I think that it is not acceptable that opening of users panel takes such a
> long time. I don't know what's exactly wrong and how to fix it. So I am
> proposing at least a workaround for Settings. What do you think?
> Unfortunately, my external webcam seems broken, so the patches are untested.
> Can somebody test it?

The patches work just fine here. I tested. ;-)

Review of attachment 361964 [details] [review]:

Why not make the CheeseCamera a GInitable and use that directly instead of working around this bug? This would help fix the same bug in Cheese.

Hmm, yes, GAsyncInitable sounds really like a good idea...

Created attachment 362801 [details] [review]
user-accounts: Prevent freeze caused by external cameras

Let's use GAsyncInitable if available. See Bug 782627.

Created attachment 362802 [details] [review]
user-accounts: Show spinner before camera monitor creation

Review of attachment 362801 [details] [review]:

Some questions below.

::: panels/user-accounts/um-photo-dialog.c
@@ +378,3 @@
 
+static void
+setup_cheese_camera_device_monitor (UmPhotoDialog *um)

This should be NULL safe I guess.

@@ +515,3 @@
+        {
+                um->monitor = cheese_camera_device_monitor_new ();
+                setup_cheese_camera_device_monitor (um);

CheeseCameraDeviceMonitor implements GInitable, its initialization might possibly fail. In that case, shouldn't we have a GError somewhere here? If that happens, setup_cheese_camera_device_monitor() will crash.

Review of attachment 362802 [details] [review]:

Looks good to me (although I admitedly might be lacking more context)

Review of attachment 362802 [details] [review]:

Looks good to me (although I admitedly might be lacking more context)

Review of attachment 362802 [details] [review]:

Looks good to me (although I admitedly might be lacking more context)

Review of attachment 362801 [details] [review]:

::: panels/user-accounts/um-photo-dialog.c
@@ +502,3 @@
 
+        /* Initialize asynchronously if possible in order to prevent freeze when opening. */
+        if (G_TYPE_IS_ASYNC_INITABLE (CHEESE_TYPE_CAMERA_DEVICE_MONITOR))

I'd rather you bumped the required cheese version when the patch has been merged. Looks fine otherwise.

Can't somebody test with the attached patches and corresponding patches from Bug 782627, please? I can't verify the patches, because I don't see this behavior anymore with the webcam which was causing this earlier...

These patches need rebase.

I rebased locally here but the bug seems to persist. It takes 3~5 seconds to load control-center/user-accounts.

What type of logs/trace from me would help you here?

Created attachment 368557 [details]
backtrace

It fixes the issue for me but raises a critical while iterating back and forth from one panel to another.

> Trying to stop a GstDeviceProvider v4l2deviceprovider0 which is already stopped

How to reproduce:

1. Open G_DEBUG=fatal-criticals gnome-control-center
2. Go to User Accounts
3. Go to Date & Time
4. Go to set 2 until the critical..

(In reply to Felipe Borges from comment #36)
> Created attachment 368557 [details]
> backtrace
> 
> It fixes the issue for me but raises a critical while iterating back and
> forth from one panel to another.
> 
> > Trying to stop a GstDeviceProvider v4l2deviceprovider0 which is already stopped
> 
> How to reproduce:
> 
> 1. Open G_DEBUG=fatal-criticals gnome-control-center
> 2. Go to User Accounts
> 3. Go to Date & Time
> 4. Go to set 2 until the critical..

I don't think you need to yo-yo between panels for the problem to appear. The problem looks like a misuse of the GStreamer API in Cheese.

Thanks for testing. But the critical is not caused by those patches, it is some bug in GStreamer, or Cheese. I see it even without those patches...

I've filed the following bug for the gstreamer critical:
https://bugzilla.gnome.org/show_bug.cgi?id=793689

Created attachment 368699 [details] [review]
user-accounts: Prevent freeze caused by external cameras

Rebased to master.

The cheese dependency has to be bumped accordingly before push!

Created attachment 369605 [details] [review]
user-accounts: Prevent freeze caused by external cameras

Cheese 2.28.0 has been finally released with the necessary API... so this patch modifies the cheese dependency accordingly... may I push this into master and gnome-3-28 as well?

Review of attachment 369605 [details] [review]:

Sure. Thank you! Please push to the appropriate branches.

Created attachment 370138 [details] [review]
user-accounts: Prevent freeze caused by external cameras

Added one more #ifdef HAVE_CHEESE to not break building without cheese...

Attachment 370138 [details] pushed as 05c86d3 - user-accounts: Prevent freeze caused by external cameras

Pushed to gnome-3-28 as well.