Multi-touch gestures aren't pixel-precise at low speeds

[AndiLavera]

What Happened

This is less of a bug and more of unwanted behavior. Touchegg gestures track fingers really well but the animations are choppy/jumpy. When you move your fingers slowly, you can see each animation "frame" jumps about 10px in size. Maybe there is a performance reason for this, but I hoping we could reduce the amount of pixels each "frame" moves.

Expected Behavior

I took a look at my wife's macbook. The animations are a bit smoother with each "jump" being only a pixel or two.

Logs

No logs to show but can be shown if requested. I imagine this is less of a "my machine" thing.

Platform Information

Manjaro Gnome with a pantheon session.

Demo

The gif below will show what I am talking about. You can see when i move my fingers consistently, the animation looks pretty smooth. However, if I slow down, you can begin to see how large each jump is.

[JoseExposito]

Hi! Thanks for the bug report.

It could actually be something related to your machine. A few questions:

• What's your screen resolution?
• Do you know the name of your touchpad?
• Do you see the same issue on the maximize window gesture? (enable it in System Settings -> Mouse & Touchpad -> Gestures)

Anyway, it could be interesting to use a linear animation between "steps" to avoid this issue, even though I don't think this is a common issue.

[AndiLavera]

This was done at 1080p. My laptop can go to 4k and I can upload a gif at that res if you would like but it's the same.
This is what google brought up about my laptop but I recommend you confirm it yourself:
Palmrest Touchpad

Laptop:
Dell XPS 9560 4k with touchscreen

Do you mean the 4 finger gestures to make windows snap left/right/max/min? If so, here is a gif:

Note: My screen recorder has some records weird colors the but the "jumps" are accurate to what I see IRL.

[cassidyjames]

@JoseExposito I am also seeing this on two machines here; the Star LabTop Mk IV and the Dell Precision 5530. In contrast, scrolling in GTK and two-finger gestures in LibHandy are pixel-precise. To reiterate, it's not an issue unless you're going extremely slowly; if we can't get pixel-precision in the movement (because it's too heavy or makes the animation too slow), an animation might be worth pursuing as lower speeds. But I would check with @Exalm and/or Handy to see how they're making it smooth, maybe?

[JoseExposito]

Great, it is good to know that we have more hardware to test with.

I can easily include a linear animation in the update phase of the gesture so, even if the hardware reports big deltas at slow speed, we can make it look nice.
I'll create a branch so you can test it. Unfortunately, I can not reproduce it with my hardware, so I'll need your help.

[alice-mkh]

I can easily include a linear animation in the update phase of the gesture so, even if the hardware reports big deltas at slow speed, we can make it look nice.

In my experience this makes it worse rather than better. See also: WebKit smooth scrolling, and how disabling it makes touchpad/touchscreen scrolling way more responsive.

[cassidyjames]

@JoseExposito oh also to clarify, it looks like I only get this on workspace switching, but not Multitasking View. So maybe it's something else going on?

[AndiLavera]

@JoseExposito I have no problem testing different branches. Ping me here with a link to the branch and I can test it out. If you require any logs, tell me how to fetch them and they are yours 👍 Thanks for taking a look!

Like @cassidyjames said, libhandy stuff is pixel perfect on my machine. When i use 2 fingers to swipe across the app menu, it's fluid.

[JoseExposito]

In my experience this makes it worse rather than better. See also: WebKit smooth scrolling, and how disabling it makes touchpad/touchscreen scrolling way more responsive.

Thanks for the tip @Exalm, you just save some time testing :D
Then the issue must be somewhere else.

@cassidyjames or @andrewc910 could you run touchegg in a terminal and, executing for example the maximize action, check if the gesture percentage printed correspond to the animation step, please?

$ killall touchegg
$ touchegg

Just to know if the issue is in the normalisation of the touchpad dimensions.

[cassidyjames]

@JoseExposito wait… if it's doing it by percentage, I think that's what we're seeing: 1% of 1920px is ~19px, which matches the step size for me (see the right side of the screenshot: it's 19px wide at one step).

[alice-mkh]

Percentage? Why :o

I mean, normalizing to a common width makes total sense (and is the only way to do it without going crazy for multi-monitor), but why not [0-1]?

[cassidyjames]

And as an addendum, swiping past the edge of the first workspace shows the "rubberband" animation smoothly (pixel-precise), versus in 19px steps like switching between workspaces.

[AndiLavera]

Gesture update detected (0%)
Gesture update detected (1%)
Gesture update detected (1%)
Gesture update detected (2%)
Gesture update detected (2%)
Gesture update detected (3%)
Gesture update detected (3%)
Gesture update detected (4%)
Gesture update detected (4%)
Gesture update detected (5%)
Gesture update detected (6%)
Gesture update detected (6%)
Gesture update detected (7%)
Gesture update detected (7%)
Gesture update detected (8%)
Gesture update detected (9%)
Gesture update detected (9%)
Gesture update detected (10%)
Gesture update detected (11%)
Gesture update detected (12%)
Gesture update detected (13%)
Gesture update detected (13%)
Gesture update detected (15%)
Gesture update detected (15%)
Gesture update detected (16%)
Gesture update detected (18%)
Gesture update detected (19%)
Gesture update detected (20%)
Gesture update detected (21%)
Gesture update detected (21%)
Gesture update detected (22%)
Gesture update detected (23%)
Gesture update detected (24%)
Gesture update detected (25%)
Gesture update detected (26%)
Gesture update detected (26%)
Gesture update detected (27%)
Gesture update detected (27%)
Gesture update detected (28%)
Gesture update detected (29%)
Gesture update detected (29%)
Gesture update detected (30%)
Gesture update detected (30%)
Gesture update detected (30%)
Gesture update detected (31%)
Gesture update detected (31%)
Gesture update detected (31%)
Gesture update detected (32%)
Gesture update detected (32%)
Gesture update detected (32%)
Gesture update detected (33%)

It goes on like that. Some duplicate values but no crazy jumps in percentage. This was for snapping a full window to the right.

Here is a screenshot of 1 "click/jump/frame". It looks pretty identical to @cassidyjames photo above. If it's 1% movements, then my jumps are 19px per frame as cassidy mentioned.

Are the animations gpu accelerated? If so, would it be possible to do like 2px jumps regardless of res? I ask about gpu acceleration because I can see 2px jumps on 4k being expensive & battery draining.

[JoseExposito]

Percentage? Why :o

Because I normalize touchpad sizes in a way that it is comfortable to perform a full swipe with independence of your device physical size.
Instead of representing swipes in deltas, I transform that to a percetage so the value is consistent independently of the device size.

But, I messed up with the type used in the protocol Gala uses and the value is being rounded, and it shouldn't.

Thanks for debugging it guys, and for pointing to the right direction Alexander, we'd be testing random stuff without your experience :D I'll fix it asap.

[AndiLavera]

@JoseExposito Oh, so the finger tracking shouldn't be integer based? But because it's currently rounding to the nearest integer, we get these "jumps"? Glad you were able to identify it so easily. Hope the fix is just as easy. Look forward to testing it out 👍

[alice-mkh]

It should be integer based, but it should round to pixel, not to a percent. So really the only place where you need to round it is right before rendering (bonus points if you use physical pixels and not logical, then it can be a bit smoother on hidpi)

[JoseExposito]

It should be integer based, but it should round to pixel, not to a percent. So really the only place where you need to round it is right before rendering (bonus points if you use physical pixels and not logical, then it can be a bit smoother on hidpi)

Those are 2 different concepts. The animation wasn't rounded, the touchpad movement deltas (after size normalization) were rounded.
However, it'll be interesting to round the animation values to physical pixels. Clutter works with floats and I guess it doesn't handle pixel alignment under the hood 🤔

Anyways, I just created a pull request that fixes the issue: #1017

[alice-mkh]

You do want to round it during the animation too, otherwise it would be blurry if you take a screenshot during the animation. And yeah, it's Clutter that should be doing it if you used its animation API.

[JoseExposito]

@Exalm I just created a different issue so we don't forget about this 👍 I think it is something interesting to have.