New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Platform-specific mouse input changes need testing #24363

Open
akien-mga opened this Issue Dec 14, 2018 · 14 comments

Comments

@akien-mga
Copy link
Member

akien-mga commented Dec 14, 2018

Godot version:
Master (cf124b1), upcoming Godot 3.1 alpha 4.

OS/device including version:
All desktop platforms with mouse input (Linux, *BSD, macOS, Windows, HTML5)

Issue description:
We just merged a handful of PRs which aim to improve and harmonize the mouse input on all desktop platforms. Some of those had been well tested and debugged during their developments, while others are still in need of more tests, but those were not happening with the PRs taking bitrot.

Hence this issue; we need you to test the current master branch (cf124b1, Calinou's next nightly build, or the upcoming Godot 3.1 alpha 4 on Sunday/Monday probably) and report any input regression that you may experience.

List of input PRs that were merged today:

  • #19191: Use XInput2 RawMotion to generate MouseMotion events [Linux/*BSD]
  • #20063: Unified button mask behavior across platforms [Linux/*BSD, macOS, Windows, HTML5]
    • And Linux fixup: #24371: Fix middle and secondary mouse buttons order
  • #20081: Fixes is_pressed when holding double click [All platforms]
  • #20385: Added double clicking to all buttons on Linux and Javascript [Linux/*BSD, HTML5]
@akien-mga

This comment has been minimized.

Copy link
Member

akien-mga commented Dec 14, 2018

If you do get a regression today and want to git bisect it, you can attempt a bisect between cfb89b6 (probably good, before those merges) and cf124b1 (last merge of input-related changes).

@akien-mga akien-mga self-assigned this Dec 14, 2018

@organicpencil

This comment has been minimized.

Copy link
Contributor

organicpencil commented Dec 18, 2018

System: Linux Mint 18 + mouse

Starting at cf124b1 3D freelook (Shift + F) is very choppy and unresponsive until I run the project the first time, after which the problem goes away.

In-game mouselook is also much less sensitive.
https://github.com/TwistedTwigleg/Godot_FPS_Tutorial

My laptop with Trisquel 8 + touchpad is kinda the opposite. MUCH higher sensitivity, doesn't have the weird choppiness.

@iirelu

This comment has been minimized.

Copy link

iirelu commented Dec 18, 2018

I just compiled bec76cf and tested things, only to discover that I'm getting the same choppiness I've been getting for months. I was definitely hoping the new PRs would fix it, but that doesn't seem to have happened. It still seemingly cuts off any one-pixel motions.
test
The same problems exist with every other form of mouse input in the editor.

Edit: Forgot to mention, this is with Manjaro Linux.

@akien-mga

This comment has been minimized.

Copy link
Member

akien-mga commented Dec 18, 2018

Starting at cf124b1 3D freelook (Shift + F) is very choppy and unresponsive until I run the project the first time, after which the problem goes away.

CC @cosmicchipsocket

@cosmicchipsocket

This comment has been minimized.

Copy link
Contributor

cosmicchipsocket commented Dec 18, 2018

Does the editor preview continue when the mouse motion hitches? There are a few possibilities off the top of my head:

  • There's an issue with how the input events are being handled
  • The events themselves are somehow coming in at an irregular frequency or with strange values
  • You're experiencing the issue where looking at materials for the first time causes momentary freezes
  • Another input device or input method is interfering somehow

Can you post a video?

@organicpencil

This comment has been minimized.

Copy link
Contributor

organicpencil commented Dec 18, 2018

Did more testing. Below are issues that occur in cf124b1, but not the previous commit 5f32fc8. Linux Mint 18.3 with a Logitech mouse.

Totally blank project
Freelook (shift + F or middle mouse), which captures the mouse, does not rotate unless the mouse is moved fast enough.
Orbital (right mouse), which does NOT capture the mouse, works fine.

In the FPS tutorial with the space skybox
Same thing. Slow - medium captured mouse is very inconsistent, right click uncaptured is buttery smooth.

The "unresponsive until first run" problem is no longer happening and may have been a PEBKAC error. I have no explanation for how it got bisected.

@guilhermefelipecgs

This comment has been minimized.

Copy link
Contributor

guilhermefelipecgs commented Dec 18, 2018

Strange, I didn't have any of this issues here.

PC with Linux 4.19.8-arch1-1-ARCH
c6edc43

@iirelu

This comment has been minimized.

Copy link

iirelu commented Dec 19, 2018

I've been looking into things a little more, and I found a curious artefact: According to InputEventMouseMotion.relative, a single pixel mouse movement to the left/right is actually 0.999023 pixels, and a single pixel mouse movement up/down is 0.998333 pixels. Judging from the mouse's behaviour when panning, orbiting, freelooking, etc in the editor, it's easy to tell that it's just cutting off the fractional part and leaving a relative motion of 0,0, but my question is, where is this strange fractional component coming from? What part of Godot's input processing pipeline causes these strange effects? Is it a DPI thing?

Edit: Uh oh. I just compiled the exact same version that I get via the AUR, and the bug is entirely fixed. No jitter, no slow-movements-get-ignored, no fractional parts, it's all fine. I'm going to spend a while looking into why the AUR version behaves differently, but for now, I think the focus (or at least, my focus) is going to turn to the godot-git AUR package. If anyone is more proficient in godot's build system and wants to save me some time, check out the PKGBUILD and see if you can find something weird that might be causing this.

@iirelu

This comment has been minimized.

Copy link

iirelu commented Dec 19, 2018

Gotcha!

Here's a table of compiler flags and their resulting effects on the size of a pixel according to XInput:

Default CXX CXX=clang++
target=debug 1 x 1 1 x 1
target=release_debug 1 x 1 0.999023 x 0.998333

As you can clearly see, the effects are exclusive to compiling with scons -p=x11 CXX=clang++ target=release_debug, and don't show up in any other combination of compiler or target. godot.x11.opt.tools.64.llvm is the only version of godot that suffers from this weird input squishing, and by extension, all the input jitteriness that comes with it.

Why? I haven't got a clue. I'm just going to edit my PKGBUILD to remove the CXX=clang++ part for the time being. I hope this information helps someone to find what on Earth is actually happening to cause this bizarre effect, but this is beyond my skill level. I think it's safe to say that the reason for the disparity behind some Linux releases being fine and some being broken in this way is entirely down to the chosen compiler flags.

@akien-mga

This comment has been minimized.

Copy link
Member

akien-mga commented Dec 19, 2018

scons -p=x11 CXX=clang++ target=release_debug

Side note, if you're overriding CXX, please also override CC, you don't want to compile C++ code with a compiler family and C code with another. (Or use use_llvm=yes which handles it already.)

@Dar13

This comment has been minimized.

Copy link
Contributor

Dar13 commented Dec 20, 2018

@iirelu I'm getting straight up segfaults from Clang 7.0.1 when compiling with target=release_debug use_llvm=yes so perhaps LLVM/Clang isn't in the most stable of places right now to begin with.

EDIT: Hmm, now a build with p=x11 use_llvm=yes tools=yes target=release_debug builds fine, only difference between it and the crashing build was that I took out a -j8. Smells of a concurrency problem, but builds fine (with multiple jobs going at once) without the -j8. Strange.

@Dar13

This comment has been minimized.

Copy link
Contributor

Dar13 commented Dec 21, 2018

When I remove the -ffast-math option from the compile options for the LLVM build the 1 pixel moves are back to their non-fractional state as they are in the GCC build:

~ GCC LLVM
-ffast-math, release_debug 1 x 1 0.999023 x 0.998333
no -ffast-math, release_debug 1 x 1 1 x 1

Clang doesn't have the fine-grained optimization flags for floating-point optimizations like GCC does so I can't narrow it down further than this.

@akien-mga

This comment has been minimized.

Copy link
Member

akien-mga commented Dec 21, 2018

@iirelu @Dar13 Could one of you open a dedicated issue for this clang -ffast-math issue?

@asheraryam

This comment has been minimized.

Copy link
Contributor

asheraryam commented Dec 30, 2018

OK so I found it weird that mouse capture wasn't working on windows since it didn't seem related to the latest commits, so I searched the PR list for input changes and it seems this was the culprit #20523

Quote:

When captured mouse position will always return center of the window and speed will return 0.
I think this is okay, because they aren't really relevant when capturing mouse. Right?

Using event.relative instead of event.position fixes the issue, but I think it should be more obvious in the docs.

I found it in the class reference for InputEventMouseMotion but I think it might go into the tutorial page here as well. Is a PR welcome for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment