Closed HEAVYPOLY closed 3 years ago
I can't see any difference. Are you using external mouse or trackpad? Also, what's mouse polling rate is set to? AFAIK there's no built-in way to set/get it on macOS, but software from the mouse manufacturer should be able to change it. macOS usually handle "gaming" mice with high polling rate really poorly, if you are using one of these try setting polling rate to 500 HZ or lower.
@bruvzg I'm using a wacom intuos tablet. Also getting the same result with trackpad. Changing project settings > debug > fps to 15 will make the delay more obvious. Also faster strokes will show the delay. The strange thing is that replacing InputEventMouseButton.press with InputEventKey.press fixes the delay. I thought it might be something to do with gesture recognition or doubleclick detection but not sure..
Ok, another interesting finding: Mouse BUTTON_RIGHT works with no delay while BUTTON_LEFT has delay...
Could it be drag stuff in viewport.cpp?
if (mm.is_valid()) {
gui.key_event_accepted = false;
Point2 mpos = mm->get_position();
gui.last_mouse_pos = mpos;
Control *over = NULL;
// D&D
if (!gui.drag_attempted && gui.mouse_focus && mm->get_button_mask() & BUTTON_MASK_LEFT) {
gui.drag_accum += mm->get_relative();
float len = gui.drag_accum.length();
if (len > 10) {
{ //attempt grab, try parent controls too
CanvasItem *ci = gui.mouse_focus;
while (ci) {
Control *control = Object::cast_to<Control>(ci);
if (control) {
gui.dragging = true;
gui.drag_data = control->get_drag_data(control->get_global_transform_with_canvas().affine_inverse().xform(mpos) - gui.drag_accum);
if (gui.drag_data.get_type() != Variant::NIL) {
gui.mouse_focus = NULL;
gui.mouse_focus_mask = 0;
break;
} else {
if (gui.drag_preview != NULL) {
ERR_PRINT("Don't set a drag preview and return null data. Preview was deleted and drag request ignored.");
memdelete(gui.drag_preview);
gui.drag_preview = NULL;
}
gui.dragging = false;
}
if (control->data.mouse_filter == Control::MOUSE_FILTER_STOP)
break;
}
if (ci->is_set_as_toplevel())
break;
ci = ci->get_parent_item();
}
}
gui.drag_attempted = true;
if (gui.drag_data.get_type() != Variant::NIL) {
_propagate_viewport_notification(this, NOTIFICATION_DRAG_BEGIN);
}
}```
@HEAVYPOLY Try calling Input.set_use_accumulated_input(false)
in your main script's _ready()
function to disable input accumulation.
Getting the same result with Input.set_use_accumulated_input(false). Still perplexed why BUTTON_RIGHT and KEY pressed work as expected but BUTTON_LEFT doesn't (I put all 3 on the same input action)
OS: Fedora 33, KDE + KWin with compositing disabled
Display: 144 Hz (V-Sync enabled disabled, FPS forced to 60)
Mouse: Logitech G901 Lightspeed in wireless mode with 1000 Hz polling rate
I can't reproduce this on 3.2 Git ecf432abc. The strokes look very similar and I can't notice a difference in terms of drawing latency either.
First row has strokes drawn using the mouse's left button, second raw has strokes drawn using the space bar:
@Calinou I've found that lower framerate makes it more pronounced, can you try with project settings > debug > force FPS set to 10fps? And Vsync disabled
@HEAVYPOLY This is with FPS forced to 10 and V-Sync disabled:
Mouse strokes on the top row, keyboard strokes on the bottom row. I can't notice a latency difference either.
This is what I get with 20FPS forced. (Mouse on top, Keyboard on bottom) My input polling is linked to FPS...seems like yours isn't somehow? Wonder why our results are so different
and with 144forced fps, not too noticeable:
This issue is likely macOS-specific, but I don't have macOS hardware to test it.
It's happening on windows, android and ios too...input frequency is linked to FPS
on linux polling rate is independant?
err is it possible to try with a lower polling rate on your logitech mouse? Also you have to move relatively fast to see the jump on the first points
I have disconnected points in the similar manner, polling rate is probably the same. But still no lag with mouse. Sometimes it happens with the keyboard input (on the screenshot tho only missing stroke part is marked with blue).
err is it possible to try with a lower polling rate on your logitech mouse?
I can't find a way to decrease the mouse polling rate on Fedora, sorry. The Arch wiki page doesn't list any commands I can seem to find in the Fedora repositories and Solaar doesn't expose a way to change the USB polling rate.
ok found another interesting thing. I plugged in a mouse and the first point is registered while trackpad misses the first point.
On top of that, mouse right has a more consistent spacing of points than mouse left
This video has sound and prints to show and hear the click delay left vs right https://user-images.githubusercontent.com/24432677/107422599-14d24b00-6ad0-11eb-8baa-2ce8c49bcc71.mov
Arghh... it was a window snapping app stealing left mouse input on Mac. I remember noticing it on windows, maybe also related to window snapping. I will do some more testing on windows and report back. Sorry for the non Godot bug and thanks for the suggestions so far.
Tested on windows and no delay. Sorry for the incorrect bug and thanks for helping me test. Closing now.
Godot version: 3.2.4 rc 16c7a3b1b
OS/device including version: Mac OSX MacBook Pro 2015
Issue description: InputEventMouseButton has small delay before event.pressed is registered Compared to InputEventKey .pressed which is correct/instant
Minimal reproduction project: Try drawing a quick stroke using mouse press, then an identical stroke using key press. the beginning of the stroke has a delay/less points recorded on mouse press
mouse_delay.zip
Small video of the issue https://user-images.githubusercontent.com/24432677/107295275-ea2ab880-6a23-11eb-8ccc-fd980b33242a.mov
Delay becomes more obvious with a lower framerate limit: https://user-images.githubusercontent.com/24432677/107301277-0d5b6500-6a30-11eb-8e1a-32d2191b70f4.mov