mouseevents in WGLMakie are not reliable

[bjarthur]

with the master branch of Makie on M2 apple silicon and chrome, double-clicking on the MWE below consistently works in GLMakie, but maybe only half or less of the time with WGLMakie:

using WGLMakie
f = Figure()
a, s = scatter(f[1,1], rand(10))
mouseevents = addmouseevents!(a.blockscene, a.layoutobservables.computedbbox)
onmouseleftdoubleclick(_->println("hi"), mouseevents)

sometimes one can "reset" the state in WGLMakie by focusing on a different window in your OS desktop, but not always.

[SimonDanisch]

Is that a regression or have you just used master to make sure you have all the newest fixes?

[bjarthur]

doubleclick mouseevents are unreliable on the latest release too (but just for WGLMakie), so not a (recent) regression:

(jl_zuTLKn) pkg> st
Status `/private/var/folders/s5/8d629n5d7nsf37f60_91wzr40000gq/T/jl_zuTLKn/Project.toml`
  [e9467ef8] GLMakie v0.10.17
  [276b4fcb] WGLMakie v0.10.17

can you reproduce?

[ffreyer]

Maybe WGLMakie is squashing events and with #4426 they get picked up as drag instead? Or maybe WGLMakie is just too slow for the delay?

Something like

using Dates
on(e -> println(now(), " ", e), events(fig).mousebutton, priority = 100000)
on(e -> println(now(), " ", e), events(fig).mouseposition, priority = 100000)

might be useful to figure out what's happening

[bjarthur]

WGLMakie seems to be squashing events, but IIUC they are not getting picked up as drag as there are no mouse move events printed inbetween the press and release events:

2024-12-13T09:10:56.278 Makie.MouseButtonEvent(Makie.Mouse.left, Makie.Mouse.press)
2024-12-13T09:10:56.284 Makie.MouseButtonEvent(Makie.Mouse.left, Makie.Mouse.release)
2024-12-13T09:10:56.742 (175.0, 147.0)
2024-12-13T09:10:56.784 (168.0, 170.0)
2024-12-13T09:10:56.826 (151.0, 220.0)
2024-12-13T09:10:56.868 (140.0, 254.0)
2024-12-13T09:10:56.909 (135.0, 268.0)
2024-12-13T09:10:56.950 (134.0, 274.0)
2024-12-13T09:10:56.992 (133.0, 276.0)
2024-12-13T09:11:00.293 (133.0, 276.0)
2024-12-13T09:11:00.334 (144.0, 283.0)  # i single clicked once here, so there should've been another pair of press and release printed
2024-12-13T09:11:00.375 (152.0, 288.0)
2024-12-13T09:11:00.417 (168.0, 293.0)
2024-12-13T09:11:00.459 (181.0, 298.0)
2024-12-13T09:11:00.501 (195.0, 305.0)
2024-12-13T09:11:00.543 (203.0, 308.0)
2024-12-13T09:11:00.585 (208.0, 311.0)  # ditto here, i single clicked once here, so there should've been another pair of press and release printed
2024-12-13T09:11:00.626 (211.0, 311.0)
2024-12-13T09:11:00.667 (212.0, 312.0)
2024-12-13T09:11:01.809 (212.0, 311.0)
2024-12-13T09:11:01.851 (213.0, 301.0)
2024-12-13T09:11:01.893 (221.0, 268.0)
2024-12-13T09:11:01.934 (228.0, 250.0)
2024-12-13T09:11:01.976 (232.0, 242.0)
2024-12-13T09:11:02.299 Makie.MouseButtonEvent(Makie.Mouse.left, Makie.Mouse.press)
2024-12-13T09:11:02.302 Makie.MouseButtonEvent(Makie.Mouse.left, Makie.Mouse.release)

does this mean WGLMakie is just too slow?

[SimonDanisch]

Yeah, it's throttled so this could happen.
Maybe we need to move the double click logic to JS for WGLMakie, but I'm not 100% sure how to best integrate that with the mouse events...
I think we'll need a native double click event as part of scene.events::Event and use that in the mousestatemachine, which gets implemented in JS for WGLMakie and in Julia for GLMakie.

[bjarthur]

changing the drag_threshold to 0 makes no difference so i don't think #4426 is at fault.

in this simple MWE the number of missed single clicks is maybe 5%, but in a full-fledged app i have with a couple dozen widgets and DataInspector turned on it is closer to 95%.

[bjarthur]

a workaround seems to be to use addmouseevents!(..., priority=1_000_000) for my full-fledged app. is there any reason not to do this? will it mess sth else up??

[SimonDanisch]

Huh, that points to you having other long running events registered on mouse...
Maybe you need more stuff like:

on(scene.events.mouseevent) do x 
    @async do_your_event_handling
end