Here's a profile: https://share.firefox.dev/3BPW4c5

Steps to reproduce:

1. Start profiling
2. Lock the screen
3. Wait a few seconds
4. Unlock and capture the recording.

Set release status flags based on info from the regressing bug 1144638

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

I can't reproduce this. When I start the profiler, then lock the screen, then return, I don't get the markers for the RetryEnableVsync event. Is there some specific activity you are doing before starting the profile? Vsync would only be relevant, I think, for fullscreen content. Are you in fullscreen mode and if so, how do you lock from fullscreen mode?

(In reply to Brad Werth [:bradwerth] from comment #3)

I can't reproduce this. When I start the profiler, then lock the screen, then return, I don't get the markers for the RetryEnableVsync event. Is there some specific activity you are doing before starting the profile? Vsync would only be relevant, I think, for fullscreen content. Are you in fullscreen mode and if so, how do you lock from fullscreen mode?

Hmm, I can recreate with Nightly (with any content), but not with my local build. I'll figure out what's going on.

I have been able to reproduce on my local build, but only 1 out of maybe 20 tries. I will keep checking to see if there is some pattern to how I lock or unlock the screen, or add extraneous key or mouse events before unlocking. We want the vsync request to be stopped while the screen is locked (as it is in most of my attempts to reproduce), but if I can find a consistent reproduction process, then I should be able to fix whatever is going wrong here.

(In reply to Florian Quèze [:florian] from comment #0)

Here's a profile: https://share.firefox.dev/3BPW4c5

Steps to reproduce:

1. Start profiling
2. Lock the screen

Actually, the way I lock the screen is with a hot corner, set (from Desktop & Screen Saver in the system preferences) to "Put the Display to Sleep", and I reproduce consistently.

(In reply to Florian Quèze [:florian] from comment #6)

Actually, the way I lock the screen is with a hot corner, set (from Desktop & Screen Saver in the system preferences) to "Put the Display to Sleep", and I reproduce consistently.

Indeed, that makes it more often reproducible for me, too. Thank you.

(In reply to Brad Werth [:bradwerth] from comment #7)

(In reply to Florian Quèze [:florian] from comment #6)

Actually, the way I lock the screen is with a hot corner, set (from Desktop & Screen Saver in the system preferences) to "Put the Display to Sleep", and I reproduce consistently.

Indeed, that makes it more often reproducible for me, too. Thank you.

I spoke too soon. I have only been able to reproduce the issue the very first time I tested with this method. I don't know what that pattern means. I'll try with a clean profile.

This bug happens because an initial call to OSXVsyncSource::OSXDisplay::EnableVsync() fails and reschedules itself, which also fails, etc. Some options I can think to resolve this:

1. Prevent the initial failing call from being made. This is what I need a reliable reproduction case to figure out. This is the best option.
2. Reschedule the call in a different way that is tied to a change in the state that made the call fail in the first place -- not just after a period of time. This would be easier to reason about if I could reproduce, but I could make some guesses and the patch would be testable by others. This is the second best option.
3. Make the EnableVsync lie in such a case and early exit without rescheduling when it errors out. This will require making the callers do their own success checks and doing their own fallbacks. This can be built without a reliable reproduction case, but I wouldn't be able to test it.

So I'll pursue options 2 and 3 until and unless I can figure out a reproduction case.

I think this is pretty common. I just saw on my new Macbook Pro M1 that while I was away from my desk my debug build filled the terminal with many "Could not create a display link with all active displays. Retrying" warnings.

Taking this bug; I'll look at it along with the other macOS vsync bugs.

(In reply to Markus Stange [:mstange] from comment #10)

Taking this bug; I'll look at it along with the other macOS vsync bugs.

Any progress on this? I'm still seeing it and it makes profiling idle Firefox on Mac difficult: https://share.firefox.dev/3RLpLnq

No progress on bug 1759232 unfortunately. It seems worth finding a workaround for this in the meantime. But none of the options in comment 8 seem very appealing :(

The next step on the grand plan for per-monitor vsync would be bug 1769139.