search

GDQuest / learn-gdscript

Learn Godot's GDScript programming language from zero, right in your browser, for free.
https://gdquest.github.io/learn-gdscript/
Other
2.08k stars 155 forks source link

Scrolling is too fast on some touchpads #114

Closed wineTGH closed 2 years ago

wineTGH commented 2 years ago

Describe the bug

The scrolling on the Synaptic's touchpad is too fast. This is not critical but very annoying. You have to use a small scroll bar, which is VERY inconvenient on a laptop without a mouse.

To Reproduce

Just scroll on the touchpad

Browser: Firefox 95.0.1 OS: Manjaro with Gnome Desktop

Video demonstration: Click

wineTGH commented 2 years ago

I just checked: if you use this project as a native application, the scrolling is tornly, but at a normal speed. gif

KevinBatdorf commented 2 years ago

Scrolling is too fast on my Mac too

NathanLovato commented 2 years ago

I might need to know more about your system and browser because I can't reproduce the issue here. Scrolling is the same as in a debug desktop build with my touchpads in both Firefox, Edge, and Brave (Pop_OS!, gnome desktop, and Windows 10 - tested on two laptops).

wineTGH commented 2 years ago

So, maybe this information will help:

Firefox version

Neofetch command

"libinput list-devices" output:

Device: ELAN0504:01 04F3:312A Touchpad Kernel: /dev/input/event9 Group: 8 Seat: seat0, default Size: 101x73mm Capabilities: pointer gesture Tap-to-click: disabled Tap-and-drag: enabled Tap drag lock: disabled Left-handed: disabled Nat.scrolling: disabled Middle emulation: disabled Calibration: n/a Scroll methods: two-finger edge Click methods: button-areas clickfinger Disable-w-typing: enabled Accel profiles: flat *adaptive Rotation: n/a

libinput version: 1.19.3

"cat /proc/bus/input/devices" output:

I: Bus=0018 Vendor=04f3 Product=312a Version=0100 N: Name="ELAN0504:01 04F3:312A Touchpad" P: Phys=i2c-ELAN0504:01 S: Sysfs=/devices/platform/AMDI0010:01/i2c-0/i2c-ELAN0504:01/0018:04F3:312A.0001/input/input15 U: Uniq= H: Handlers=event9 mouse1 B: PROP=5 B: EV=1b B: KEY=e520 10000 0 0 0 0 B: ABS=2e0800000000003 B: MSC=20

(I wrote the wrong touchpad model)

sjml commented 2 years ago

Seeing this on my Mac laptop as well... works fine when running the project natively (or at least from the Godot editor), but in the web export the scrolling with a trackpad is so fast as to be unusable. Makes me wonder if this is something deeper in Godot. I might see if I can make a minimal repro project.

NathanLovato commented 2 years ago

We found out this issue has to do with Godot, it's not something we can solve on our end.

Here's a report to the engine. So I'm marking the bug as wontfix as it needs a fix upstream in the engine: https://github.com/godotengine/godot/issues/49873

NathanLovato commented 2 years ago

Could one of you who faces the issue test PR #201? It should fix this bug as it takes over Godot's built-in scrolling and limits scrolling speed. However, as we can't reproduce the bug in the team, we'd need someone affected by the issue to confirm this.

sjml commented 2 years ago

Is there a hosted export somewhere? Trying to figure out how to get it to build from the PR in the meanwhile but if there's an easily testable version...

SpyrexDE commented 2 years ago

@NathanLovato I tried it a minute ago on my laptop: It's not as bad as in the video, but still too fast. The problem is that Godot's scroll input event does not seem to be developed with touchpads in mind. So the event only gets called, when on the touchpad the "traveled distance" equals one mouse wheel step.

But that's just my guess, could be wrong.

NathanLovato commented 2 years ago

I guess with smooth scrolling we could cap the speed, even if events accumulate?

On our touchpads here (2 computers, Ubuntu Linux and windows 10) the scrolling is fine.

@sjml the way you would test this is by downloading the project with @SpyrexDE's changes and importing it into Godot 3.4.2. Then pressing F5 to play the app. You can download it here: https://github.com/SpyrexDE/learn-gdscript

To do so, click the green "Code" button at the top and then Download Zip.

image

SpyrexDE commented 2 years ago

@NathanLovato You are right. Lowering the speed property of my SmoothScrollContainer leads to pretty acceptable results when using my touchpad. But what I meant is that the recreation of the responsiveness as known from using Chrome/Firefox with a touchpad is not possible due to Godot's limitations. So as a consequence, I would suggest adding a scroll-speed setting so everyone can adjust the speed to their touchpad behavior.

NathanLovato commented 2 years ago

A setting would be great yes.

I was also thinking of finding a way to balance the smooth scroll speed based on the repetition of events. What I'm thinking is scrolling with a mouse wheel generates few input events in comparison with using the touchpad with two fingers, so perhaps there's a way to balance those two.

SpyrexDE commented 2 years ago

Yeah, I thought about that too but I have no idea how to detect what type of scrolling the user is performing. It's hard to differ between a fast wheel scroll and a slow touchpad scroll.

NathanLovato commented 2 years ago

The idea is not to try and differentiate them, but rather operate on the frequency of scroll events. I can´t say how exactly without trying, but the idea is to reduce the impact of scroll events if they happen too close in time. You can even do that without tracking the time between them, by using the ease function or something similar on the scroll speed value: the closer it gets to the maximum, the less scroll events add to the speed.

SpyrexDE commented 2 years ago

Although that would make scrolling on the touchpad a better experience, scrolling with the scroll wheel wouldn't feel that great e.g. when scrolling fast. What do you think about a checkbox in the settings like "touchpad mode" where you can toggle the scroll maximum?

NathanLovato commented 2 years ago

What I'm suggesting is about capping the touchpad scrolling when using smooth scrolling, that's it. That shouldn't affect the mouse wheel but rather limit touchpad issues.

And no, we shouldn't have modes or whatnot, ideally - only one scrolling sensitivity setting at most, if necessary.

SpyrexDE commented 2 years ago

Sorry, maybe I overcomplicated it a bit. But is something like capping the touchpad scrolling even needed? I think just a lower scroll speed does the job, doesn't it? It would also feel much more responsive than capping the scroll input event calls, which would have the same effect as limiting the overall scrolling velocity. I will send a comparison video in just a few minutes.

SpyrexDE commented 2 years ago

It's a decision between those two options:

I think both are better than it was before and of course, it's your decision what to prefer for this project @NathanLovato. 👍

NathanLovato commented 2 years ago

I can't tell from a video. It's something you can only see with your fingers. You can just push whatever you feel works best to the PR, we'll then complete the review, merge, and have people test this in the next update.

SpyrexDE commented 2 years ago

Well, then the easiest thing would be to add a scroll speed slider to the settings and link it with the "speed" property of the SmoothScrollContainer class.

wineTGH commented 2 years ago

It's still fast, but not as fast as it used to be. I'm waiting for engine fixes :)

scroll

NathanLovato commented 2 years ago

@wineTGH Thanks for testing. We'll add a scroll sensitivity option too for people in your situation.

claudiusraphael commented 2 years ago

This sounds pretty much like a problem with the inertia dampening built into macos and synaptics touchpads.

Macos has two options regarding that, one for an artificial lag that collects the fingermovement and reacts to it once the threshold is reached and then initiates the scroll with a sped up replay of the initial movement. The other an ease in (similar to the acceleration settings for mouse). I do not recall the naming of the option in settings, but it would require the user to change the settings systemwide to compensate for it which is clearly not an option, as it would be intrusive.

Synaptics Touchpads with gesture support and 3 finger touch have a similar dampener enabled by default which would also deliver actual (non-eased) values only if that feature is systemwide disabled via the driver settings. Again, not an option because it would be intrusive.

I have no idea how Godot handles the input, or what input it actually uses, but in web-/browser-based-/electron-/etc. -apps this dampening can be prevented/overridden by limiting the scroll to the actually shown content (basically defining a container working as the viewport), because otherwise the whole page-length is used as a basis for the pre-eased scroll-input, which in case of macos default setting leads to having to move the finger(s) quite far to actually initiate the scroll (overcome the threshold) and in case of Synaptics it overcompensates as it adjusts the actual scroll-rate based on the page-dimensions isntead of staying with the actually visible content.

So if Godot allows to define an active viewport/limit scroll to a hidden container-element where the content is nested in , this could be normalized in the browser.

A problem that arises with this workaround though is that the scroll might be interpreted separately on the actual page versus the manually defined viewport, meaning it would be necessary to accomodate for viewport-dimension changes by actively tracking the actual browser-content-dimensions by script.

Just a thought, maybe it helps.

NathanLovato commented 2 years ago

As other users reported, it's not a Mac issue.

The issue is some touchpads and browsers produce lots of input events. There's already a potential fix needing testing.

claudiusraphael commented 2 years ago

You misunderstood, or let's say i described it in a bad way:

This comment is to clarify that it is not an issue solely on "Mac" and to make aware that this is a problem spanning all major platforms in relation to Synaptics Touch-/Track-pads with Gesture/3-finger-and-more support and all I2C/PS2/USB-HID-translated devices.

What you do with that information is up to you, this was no request just a note for those who want to dig in deeper and potentially contribute.

To give a thought: "wontfix" is a statement (and justified because it is a problem caused by Synaptics in this case), but it does not require to close an issue; collecting user-reports on a matter can be helpful in the long run, because problems do not go away because we don't want to care - to proactively "do not care" (which is plenty fine) we have issue-specific notification-settings.

Have a nice one!

NathanLovato commented 2 years ago

The issue got closed by a pull request that tried to address the problem. A teammate tested it and said it did fix it.

The concrete problem we had was, as I mentioned in the previous comment, that too many scroll events were getting fired by some touchpads and some browsers. The commit in https://github.com/GDQuest/learn-gdscript/pull/218 throttles scroll events and normalizes them across computers and browsers.

You can see that we otherwise don't close issues marked as wontfix unless they get fixed: https://github.com/GDQuest/learn-gdscript/issues?q=is%3Aopen+is%3Aissue+label%3Awontfix