[2.1.0][2.1.1] Swipes lag behind on Jolla C / Aqua Fish

asked 2017-02-09 21:09:09 +0300

Giacomo Di Giacomo

8691 ●117 ●144 ●160

updated 2017-09-19 17:21:01 +0300

DarkTuring

6918 ●221 ●320 ●327

https://DAB.com/

Testing on Intex Aquafish 2.1.1.26 swipe lag exists while it was gone on 2.1.0.11.

In version 2.1.0.9 swipes are lagging almost 1 cm behind my finger. In earlier versions the swipe edge lied right under the finger. Problems often occur when the user is typing fast on the keyboard or any other fast touch interaction and then try to swipe from the edge. I strongly suspect this is due to excessively aggressive Kalman filtering that is unable to predict the movement. Other problems caused by the same issue is that sometimes a quick swipe is recognised as a tap instead triggering some unintended actions. Jolla 1 and Jolla Tablet seem to be unaffected by this issue.

Here's how to reproduce swipe lag:

Open a text box.
Type Q button for a long time enough to fill two lines.
Do a quick swipe right after typing and hold your finger.
You should see the edge lag behind your finger.
Try a couple of times since it doesn't seem to happen every time.

Here's how sometimes swipes get interpreted as taps: Misinterpreted swipe resulted in a stuck hold

EDIT: Seems to be still there somewhat in 2.1.1.23.

EDIT 08-09-2017: The problem is still there stronger than ever. Swipes often fail, I have to swipe three to four times to close an app, a full horizontal swipe is often not enough to show the home screen, and unwanted calls are made due to poor responsivity of the dialer interface. I had to disable the filter to make the phone usable, so I won't be able to give further feedback. I will enable it again when/if any change is made to the behaviour.

edit retag flag offensive close delete

Comments

11

Just was about to fill out the same bug with the same suspect (Kalman filter). They are also very slow and sluggish - to my experience, it happens with the first edge swipe - when you do not lift your finger from the screen and keep swiping back and forth, subsequent swipes are swift. Only the first one is very (!) sluggish. It almost feels like pushing away a heavy rock, compared to the situation before.

Not sure if related, but lags reported with the Developer mode frame rate visualization are twice as big for the first swipe.

nodevel ( 2017-02-09 21:50:55 +0300 )edit

1

totally agree on this!

tortoisedoc ( 2017-02-09 22:57:00 +0300 )edit

2

@tortoisedoc please convert that into a comment...

ced117 ( 2017-02-09 23:00:54 +0300 )edit

I strongly suspect you having something cluttering, as apart from the occasional lag, I do not see what you mean.

chemist ( 2017-02-09 23:49:21 +0300 )edit

4

Apparently he's not the only one to notice... It was the single biggest issue I have with the new update. This Kalman Filter thing is either not optimized or simply not suitable for quick interaction. I have adapted to the old UX, I NEVER made swiping mistakes or anything that would justify this. If people have problems with fine motorics okay. But forcing this on everyone is bad.

MoritzJT ( 2017-02-10 01:11:15 +0300 )edit

38

answered 2017-02-10 12:46:40 +0300

Joona Petrell
1383 ●12 ●21 ●20

http://www.joona.net/

We did change how the touch filtering is implemented. Now the touch and painting frames are better synced together, removing stutter during drag and flick animations. But at the same time it is true that the reliability of edge swipes has regressed, quick swipes don't always get detected (especially during system load or if you haven't used the device for over half-dozen seconds).

Sorry, we will look into it.

edit flag offensive delete publish link

Comments

4

I hope we can get this fixed before the whole update goes public. I'd be really sad to have to live with this another update cycle. Downgrading also isn't really an option.

Keep up the good work!

MoritzJT ( 2017-02-13 17:34:02 +0300 )edit

there was no problem for me before the update, now it is.

please just undo it

pawel ( 2017-02-14 23:55:28 +0300 )edit

I hope closing app cover from Home screen may become faster After official release Iijoki 2.1.0.9, Till then It needs to force close app by swipe down gesture

p_pahare ( 2017-02-15 08:48:44 +0300 )edit

Is there any command-line magic that could be applied to revert this behaviour in the meantime? Using Sailfish on Jolla C is very frustrating experience at the moment.

ajalkane ( 2017-03-22 08:11:47 +0300 )edit

1

I noticed after the latest update, the problem still occures when you try to dismiss an alarm for example and when you swipe up you pull over your finger the screen edge, usually is not working, but when you don't pull over it is usually working... Strange behavior, better, but still not same good as it was before.

liqquid ( 2017-03-27 01:56:59 +0300 )edit

9

answered 2017-06-02 18:03:34 +0300

DarkTuring

6918 ●221 ●320 ●327

https://DAB.com/

You can disable the introduced touch filtering by removing ":filtered:prediction=16" from LIPSTICK_OPTIONS defined in /var/lib/environment/compositor/droid-hal-device.conf. We are too small company to maintain multiple implementations of different functionalities so use at your own risk.

BTW In 2.1.1 we have fixed the lag reported above, and further reduced the thresholds to make edge swipe easier. Joona Petrell (5 hours ago)

@Joona i reposted as solution, this has gotten rid of really pesky delays all over the UI touch interface, swipe, select, right swipe, etc.

edit flag offensive delete publish link

Comments

@DarkTuring, you mean @Joona Petrell - Joona (singular), is a different user altogether.

Spam Hunter ( 2017-06-02 19:29:50 +0300 )edit

4

edge gestures are indeed more reliable but the lag and swipes interpreted as taps still occur. I consider this is still NOT resolved.

Toxip ( 2017-07-24 15:58:52 +0300 )edit

2

Too small a company to maintain multiple implementations of different functionalities? Sorry but if you release stuff that actually introduces a regression for a certain portion of your userbase, then simply don't introduce such a change in the first place. Have you heard even ONE comment of thanks regarding karman filtering? Just ONE comment telling you that it was a good idea, that it has helped anyone with daily interaction?

I hope the suggested fix removes it entirely.

MoritzJT ( 2017-07-24 16:34:13 +0300 )edit

Me too same problem. when ever click in keyboard and swipe show me lags and bugs in keyboard. We soon next update fix it

Rafaelvlmendes ( 2017-07-25 00:42:49 +0300 )edit

2

I removed "filtered:prediction=16" from that line after /dev/touchscreen and now the Lag while keyboard typing is very little but threshold swipe to minimize app to cover increased which I can tolerate .

p_pahare ( 2017-07-25 07:01:11 +0300 )edit

2

answered 2017-11-26 14:02:31 +0300

mcfrisk
3892 ●71 ●93 ●95

Even when the filter is disabled swipe is horribly laggy if app covers need to regenerated: https://together.jolla.com/question/174850/swipe-lags-when-returning-to-running-apps-grid-if-app-cover-is-not-uptodate/

edit flag offensive delete publish link

2

answered 2018-02-25 23:35:12 +0300

olf
10393 ●104 ●201 ●158

updated 2018-02-25 23:37:10 +0300

To disable the Kalman filter one may install Toxip's Patch "Disable kalman filter" for Jolla C/AquaFish or Inoi R7 and apply it in Patchmanager.

edit flag offensive delete publish link

1

answered 2018-04-05 11:38:37 +0300

mcfrisk
3892 ●71 ●93 ●95

Feels like jolla is not really testing SW releases on jollac at all or SW updates are not reliable. This laggy behavior of whole UI is so prominent and impossible to miss.

edit flag offensive delete publish link

[2.1.0][2.1.1] Swipes lag behind on Jolla C / Aqua Fish

Comments

5 Answers

Comments

Comments

Question tools

Stats

Related questions

[2.1.0][2.1.1] Swipes lag behind on Jolla C / Aqua Fish

Comments

5 Answers

Comments

Comments

Question tools

Public thread

Stats

Related questions