With just a few windows opened on macOS left clicks take 1-2 seconds to enter application's pipeline from SDL_PollEvent, but right clicks are immediate, and all is OK on other platforms.

[slajerek]

I have this problem that I am trying to chase for quite a long time. Originally I thought that was because of the high CPU usage of underlying application logic, so I left that as-is. A few days ago I debugged this further and with switched-off application logic, the problem is the same. I have a simple rendering pipeline with ImGui that opens approx. 7 SDL windows. The ImGui is not a bottleneck here I think as the problem goes away on Windows and Linux, both run as VMs on the same macOS and the same codebase. There is no such delay there. The problem also goes away when there's only one opened window on macOS. That's why I am thinking that problem may be in the SDL itself.

Normally click experience is like this (I can video the problem if required):

Mouse left clicks:

1. Click the left mouse button.
2. See the rendering pipeline and SDL_PollEvent loop every ~20ms, no blocks etc., usual smooth loop.
3. 2 seconds later I see that SDL_MOUSEBUTTONDOWN event entered the pipeline.
4. Parse the event for 2ms, ImGui parses its events for like 1ms.
5. Repeat the steps above to confirm the problem.

Mouse right clicks:

1. Click the right mouse button.
2. See that the rendering pipeline and SDL_PollEvent received the SDL_MOUSEBUTTONDOWN event immediately.
3. Parse the event for 2ms, ImGui parses its events for like 1ms.

I assume this may be related to windows switching on macOS with a left mouse button click, or maybe similar to issue #2497
The problem is on macOS Catalina 10.15.7, both Release and Debug versions of the app. The problem does not exist on Linux/Windows.

Any thoughts on what may cause this problem? Thanks in advance.

[slime73]

Are you using a while-loop each frame to process all events that have been generated since the previous frame, or is your code just processing one event per frame?

[slajerek]

This is fairly standard while loop, the actual code can be found here: https://github.com/slajerek/MTEngineSDL/blob/master/src/Engine/Core/VID_Main.cpp

In the VID_RenderLoop() and VID_ProcessEvents()

I am processing all the events in a while loop. There's indeed a crude hack to stop processing events and force-paint the next frame if the processing takes too long, but it does not have any impact on the problem described here (the same behavior is with commented-out code and all the processing takes a few milliseconds, so the break is not executed). Also, I am fetching mouse coordinates using SDL_GetGlobalMouseState, and I read somewhere that is not recommended in the event loop, although this does not have also any impact on the behavior when I comment that out. I also have an event filter (SDL_SetEventFilter), but that also does not have any impact when removed.

This is a video of the issue, note when I press left button I see the event in logs after 1-2 secs, and when I press right button, I see the event in logs immediately: https://www.youtube.com/watch?v=cAvo6aQryv8

Confirmed that this problem exists in SDL 2.24.1

Thanks.

[icculus]

So I don't know what is causing this yet, but here's a basic reproduction case that does not trigger the bug on a Mac (M1 Mac Mini, macOS Monterey 12.6) for me:

• build latest SDL from source
• build the test apps
• run SDL_EVENT_LOGGING=1 ./testsprite2 --windows 2

This will log to stderr each time an event is added to the SDL queue (except mouse motion, since it's spammy). Then I found the two windows on my desktop, and tried clicking them as fast as I could with the left mouse button, then the right just to test.

They arrived pretty much immediately to either window, left or right button.

Video of this, where I click left as fast as possible on different windows, then right.

https://www.youtube.com/watch?v=OupTLGD2rgg

Can you try this and see if you get similar results? It might be something on your system or something in MTEngineSDL and I'm trying to eliminate some possibilities here.

[icculus]

Oh, one other thought...right clicks go to background windows on mac immediately. Left clicks on background windows will raise the window and throw the click away, so it's not until the second click that you get an SDL_MOUSEBUTTONDOWN event. Are you seeing that, and thinking that second click is the first click coming through very late?

If this is what's happening, and you don't like it, set this hint at startup:

SDL_SetHint("SDL_MAC_MOUSE_FOCUS_CLICKTHROUGH", "1");

(EDIT: Apparently you can use SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH--a symbol--across Windows/Mac/X11, instead of "SDL_MAC_MOUSE_FOCUS_CLICKTHROUGH"--a string--but that's pretty new...older SDLs have supported the string on macOS only for awhile now, and will still check it if the symbol version isn't set.)

[slajerek]

Thanks, I will check the updated test and get back. Note, with 2 windows it is also quite quick on my system, I think the problem starts when there are more windows open. Btw. I have the SDL_MAC_MOUSE_FOCUS_CLICKTHROUGH already set. Anyway, I'll post more details soon.

[slajerek]

@icculus I've been able to reproduce this problem with a larger number of windows with testsprite2, but I had to show more windows. With SDL_EVENT_LOGGING=1 ./testsprite2 --windows 30 left click lags as on my video, but the right click is immediate. The number of windows is of course larger, not sure why this exposes in such a way in my case with a bit smaller number of opened windows. If I increase the number of windows to, say, 50 then this is very visible. I instantly see in logs right-click events, but the left-click is lagged.

[slajerek]

I did some more digging. And when I switched off rendering by commenting out line 368 MoveSprites() then the problem goes away. So this may be related to rendering logic, swapping buffers (?), etc. Not sure why this regards only left-clicks and not right-clicks, drawing is fast and does not depend much on the number of windows (i.e. rendering queue definitely does not lag with a large number of opened windows in this test), and also does not happen on the same machine in Linux/Windows VMs.

There's also one other thing that I spotted that may or may not be related. When I open OS window, like NSOpenPanel using a standard ObjC call

dispatch_async(dispatch_get_main_queue(), ^{
		NSOpenPanel *panel = [NSOpenPanel openPanel];

This panel sometimes needs a very long time to appear and looks like events are stuck or are in a low-priority events queue or something - simply switching to another app and back shows the panel immediately in such a situation.

[icculus]

This doesn't reproduce for me with SDL_EVENT_LOGGING=1 ./testsprite2 --windows 30 either...I don't know what to tell you at this point; it might be something about your system...?

[slajerek]

Yeah, this is really interesting. This does not happen with any other apps and I tested this carefully. This does not happen on VMs. Indeed I have quite old Catalina here 10.15.7, maybe that's the reason. I'll try to compile SDL2 under Xcode and do some profiling directly.

[slajerek]

FYI. We tested this on macOS Ventura and works perfectly. This must then be related to Catalina or something with my OS. I am going to do more tests, but it seems this is specific to an older versions of macOS, so I'd not bother much then.

[slouken]

Great, thanks for the update.