Perceived responsiveness of the UI

Thanks a lot for the patch !
Is there a way to custom the swipe to event view speed animation please ?

To me it feels like SF has a delay in reacting to a scroll. Indeed it even flashes an item in a list as if it was selected, before the scroll starts. This leads to a constant sense of the UI being sluggish.

Yes the somehow sluggish scroll is there. The flash however is a reaction to touch. And is unrelated to the scroll. The nintendo switch interface does it also.
Android -at least the device i test- ā€œhidesā€ it by delaying the item selection. I have no idea how iOS handles that.

I think Sailfish is using very simplistic algorithms(?) for transitions in ui. It doesn’t react to different accelerations applied when swiping, ie physics of swipes seems unnatural when compared to for example Nokia N9 or very natural feel of Miui from Xiaomi. And transitions are slow too, or linear and thats why seemingly slower? I’m no programmer myself, just trying to put to words the perceived differences compared to my other phones.

2 Likes

It may or may not be unrelated, but it is disturbing as it hints at an interaction happening with that particular element, even though you are scrolling a whole list and not concerned about an individual item… On other platforms there is a flash too, but only if you actually clearly press on the item to open it or select it. I would venture that it would feel more tactile to delay the flash ever so slightly, so it doesn’t appear when scrolling.

Obviously the scrolling also should not be delayed, as that makes it feel sluggish.

1 Like

I’d also like to see it go. I am not defending it.

2 Likes

I also want to add:

  • Keyboard appearing when taping a text field.
  • Browser bar appearing when scrolling.

In general every transition of the os is waaaaayyyy tooo slow.

1 Like

One more thing is how long it takes before an alarm you dismissed or snoozed finally stops occupying the screen. The sound and vibrations are muted as soon as you dismiss, but the reminder stays on screen for what feels like an eternity and prevents you from doing anything else unless you wait for it to go away or swipe from the left/right side. It should disappear as soon as you select ā€˜Dismiss’, without any delay.

1 Like

Just coming back to this because i got to play with an ios device. iOS uses the same solution as android. From the time you touch there is a delay in the flash. If you touch and scroll immediately the ā€œflashā€/reaction to touch doesn’t happen.

SFOS can solve it the same way (introduce a delay) i believe.

I definitely believe some simple tweaks on that could give the appearance of more fluidity. The delay seems very short, but perhaps that is all that is needed, and a little bit of fuzziness about how much finger movement is considered enough for the flash to be cancelled and for scrolling to start.

The topic -general feel of the OS- was disused in a community meeting a few weeks back and joona was made aware of this topic. There is not ETA though since some areas require a newer Qt.

I’d like to add to the already mentioned points:

  • screen wake up animation is too slow
  • with the finger already on the fingerprint sensor, it won’t unlock the device right away, instead, you have to lift the finger and tap again

This, in addition to the general inaccuracy of the fingerprint sensor results in multiple trial&error attempts rather than quick and straight unlocking.
I have so say though that compared to the XA2 the 10ii sensor is worse, but positioned better. The XA2 sensor was more precise, however being on the backside, it was always like tapping a few times to hit it.

Also:

  • swiping from left screen inside to show the homescreen often doesnt work. I have to carefully position the finger to make it work. often I need several attempts
  • same for the swipe-down to close
  • it would be nice to light up the display by tapping it, or have the accelerometer enable it

When compared to gestures on e.g. the iPhone (the one with FaceID / no home button), I am always stunned by just how precise it is and well it works.

Those are small things, and surely non-critical. However its those small things that turn a mediocre/good user experience into a great user experience.
Or the other way round: Not done right it introduces annoyances which accompany the user all the time and might lead to frustration sooner or later.

1 Like

I’ve found this to be a problem mostly on the Xperia 10 II. I’ve had some wrong edge swipes on the Jolla 1, Tablet, C and Xperia X, but it’s very noticeable on the Xperia 10 II.

Could it be that another part of your hand is touching the screen. Multi touch doesn’t quite work and if you touch the screen with a part of your hand the movement of your finger wont register.

Hey, Kuba77. Is there a chance that you could update the patch again to work on SFOS 4.5 (64-bit version)?

Please also 32 Bit :pray:

1 Like

The latest update doesn’t work on Xperia XA2 Ultra 5.0.0.67


pm_apply 2025-04-22T20:19:58+02:00

patch-animation-settings-iii

Using patch file: /usr/share/patchmanager/patches/patch-animation-settings-iii/unified_diff.patch


Checking paths for 32-bit → 64-bit conversion

Mangle candidates: /usr/lib64/qt5/qml /usr/lib64/jolla-mediaplayer /usr/lib64/maliit/plugins

OK, found nothing to convert.


Test if already applied patch

checking file usr/lib/qt5/qml/Sailfish/Silica/PageStack.qml
Unreversed patch detected! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored
checking file usr/lib/qt5/qml/Sailfish/Silica/private/PulleyMenuBase.qml
Unreversed patch detected! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored
The next patch, when reversed, would delete the file usr/share/jolla-settings/entries/patch-animation-settings.json,
which does not exist! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
The next patch, when reversed, would delete the file usr/share/jolla-settings/pages/patch-animation-settings/main.qml,
which does not exist! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
The next patch, when reversed, would delete the file usr/share/jolla-settings/pages/patch-animation-settings/SpeedSlider.qml,
which does not exist! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored
checking file usr/share/lipstick-jolla-home-qt5/launcher/Launcher.qml
Hunk #1 FAILED at 18.
Hunk #2 FAILED at 85.
Hunk #3 FAILED at 131.
3 out of 3 hunks FAILED
checking file usr/share/lipstick-jolla-home-qt5/layers/EdgeLayer.qml
Unreversed patch detected! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
4 out of 4 hunks ignored
checking file usr/share/lipstick-jolla-home-qt5/layers/HomeLayer.qml
Unreversed patch detected! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
3 out of 3 hunks ignored
checking file usr/share/lipstick-jolla-home-qt5/layers/StackLayer.qml
Unreversed patch detected! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
4 out of 4 hunks ignored
checking file usr/share/lipstick-jolla-home-qt5/main/PeekArea.qml
Unreversed patch detected! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
5 out of 5 hunks ignored
checking file usr/share/lipstick-jolla-home-qt5/switcher/SwitcherItem.qml
Unreversed patch detected! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored
checking file usr/share/lipstick-jolla-home-qt5/topmenu/AmbienceSelector.qml
Unreversed patch detected! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
4 out of 4 hunks ignored
checking file usr/share/lipstick-jolla-home-qt5/topmenu/TopMenu.qml
Unreversed patch detected! Ignore -R? [n]
Apply anyway? [n]
Skipping patch.
5 out of 5 hunks ignored


Dry running patch file

checking file usr/lib/qt5/qml/Sailfish/Silica/PageStack.qml
Hunk #1 succeeded at 80 with fuzz 1.
Hunk #2 succeeded at 121 with fuzz 1.
checking file usr/lib/qt5/qml/Sailfish/Silica/private/PulleyMenuBase.qml
checking file usr/share/jolla-settings/entries/patch-animation-settings.json
checking file usr/share/jolla-settings/pages/patch-animation-settings/main.qml
checking file usr/share/jolla-settings/pages/patch-animation-settings/SpeedSlider.qml
checking file usr/share/lipstick-jolla-home-qt5/launcher/Launcher.qml
Hunk #1 FAILED at 18.
Hunk #2 succeeded at 74 (offset -4 lines).
Hunk #3 succeeded at 120 with fuzz 1 (offset -4 lines).
1 out of 3 hunks FAILED
checking file usr/share/lipstick-jolla-home-qt5/layers/EdgeLayer.qml
checking file usr/share/lipstick-jolla-home-qt5/layers/HomeLayer.qml
Hunk #3 succeeded at 243 with fuzz 1.
checking file usr/share/lipstick-jolla-home-qt5/layers/StackLayer.qml
Hunk #2 succeeded at 329 (offset 1 line).
Hunk #3 succeeded at 378 with fuzz 1 (offset 1 line).
Hunk #4 succeeded at 402 (offset 1 line).
checking file usr/share/lipstick-jolla-home-qt5/main/PeekArea.qml
Hunk #3 succeeded at 96 with fuzz 2 (offset 1 line).
Hunk #4 succeeded at 156 (offset 1 line).
Hunk #5 succeeded at 168 (offset 1 line).
checking file usr/share/lipstick-jolla-home-qt5/switcher/SwitcherItem.qml
Hunk #2 succeeded at 175 with fuzz 2 (offset 35 lines).
checking file usr/share/lipstick-jolla-home-qt5/topmenu/AmbienceSelector.qml
checking file usr/share/lipstick-jolla-home-qt5/topmenu/TopMenu.qml
Hunk #4 succeeded at 331 (offset 16 lines).
Hunk #5 succeeded at 463 (offset 16 lines).

*** FAILED ***

@ApB and fellows,

I found this thread right now and take the opportunity to suggest this thread:

In short: The delays and lazy/delayed UI feeling is NOT from an old QT version and also not from weak hardware. It is implemented by Jolla with intention. Whatever what this intention may be, I don’t know and I can’t imagine. There is a huge amount of intentionally coded delays and durations in the .qml files in the /usr/share/ and /usr/lib/qt5/qml/ paths including subdirectories.

TLDR:
I use a Xperia 10, 6 yrs old, now it feels like using a top modern phone. Meanwhile I’ve got a small collection of X10’s and a Xperia X too, because a friend with his family left SFOS and gifted me his old devices and also I bought a few second hand devices over the time (for experiments).

Last summer I took the effort and searched them all (not the phones :wink: , but the delay and duration arguments in the qml files), and set a lot of delay and duration arguments to (partly significant) lower values manually by CLI. Now, result is a snappy full functional GUI, less hangs and crashes and faster app launching, e.g. LLs Video Player: Starts in one second, loads list of 1800 videos including pics in another second. Tap to start playing 1 sec for a 8min video, Tap to start time 1,5 sec for a 60 min video. No more crashes.

See thread mentioned above, and that’s not all. In the last few weeks I found a few more, tweaked and tested in the last weeks. It’s only a small number that will come soon. Also I’ll check and revise everything in the next 2 weeks.

Then the final version of my tweak list is posted completely and I’ll change this on my device not any time soon! Enjoy and I’ll be happy to read some feedback.

BUT, a small disadvantage is with my list, I have to confess: It’s for SFOS 4.5.0.24/25. Because I started the work in last summer (2024). The basic problem of lazy UI persists since many many years. But I’m sure, one can find differences on newer SFOS’es, other line numbers for similar code parts and so on and I hope someone posts an up to date list for the recent/latest SFOS.

1 Like

I can imagine one reason why they might have added those delays: for the feel of the system.

Having well chosen delays in certain parts of the User Interface will give a specific feel to the UI.

Having zero delays can feel generic and bland sometimes.
So I could totally understand the reasoning if that is why they did it.

1 Like

Of course there have to be some delays in the program structure. Otherwise the touchscreen and UI will not work. But they are much too long. Abt. 1/4 of the original value is mostly good, some values can be much shorter but mostly optimum is 1/4. And imho a lot of graphical effects and transition effects are simply annoying and nothing else.

rant on
Is SFOS really an OS (operating system) or more an artwork? Permanently having to wait for the mega slow UI response really sucks.
rant off

Q: As Jolla permanently complains about too less resources, too less manpower and too much other important things to do, why do they have time and recources to code hundreds of lines with graphical effects every new edition? Can anyone tell me?