Search Unity

ScrollView has a few bugs

Discussion in 'UI Toolkit' started by perholmes, Aug 27, 2021.

  1. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    233
    Hi,


    The UIElements ScrollView has a few issues when operated with touch:

    Issue #1: Elasticity ignores ScrollView mode.

    Regardless of whether a ScrollView is only Horizontal or Vertical, in elastic dragging mode, you can pull in all directions, including horizontally in a vertical scroll view, basically pulling the scroll view off the rails.

    Issue #2: Flick velocity is calculated incorrectly

    Flick velocity is calculated incorrectly. Try to scroll up or down without letting go, wait 2 seconds, and then let go. The scroller suddenly flies off. The scroller isn't actually calculating a velocity (distance over time), it's only measuring the delta between the last two events, even if there are 10 seconds between them. The correct behavior would be to take the time between the two events into account to calculate an actual velocity. The scroller should also do nothing if the time between the last two deltas is more than a second, because this is likely not intended as a scroll, but a user changing their mind about scrolling at all. Currently, a decision to not scroll results in a scroll.

    Issue #3: Scroll animation frame rate

    Scroll animation has a different framerate than actual scrolling. In an app that runs that 60 fps per second, you'll have the full frame rate while the finger is on the scroller, but the flicking frame rate immediately drops to 30 fps when you flick and let go. I think the timer that's running the scroller animation is only being sampled at 30 fps.

    Issue #4: Deceleration curve is extremely non-linear

    The deceleration curve is based on multiplying a number with the speed, so 0 means immediately stopping, and 1 means going forever. However, the values in between don't result in smooth deceleration, and the view hits a minimum speed you can't get under regardless of deceleration value, unless you set it to zero and stop all scrolling. A value of 0.1, results in an abrupt deceleration to about 30% speed, and over the next 10 seconds, it only decelerates a little bit more. It feels like there's a decimal error and the calculation is done in integers, because the curve quickly hits a floor of a minimum speed it can't get under unless you disable flicking completely.

    Also, multiplication isn't a great way to decelerate, because it has an extremely long tail, and mathematically goes on literally forever (at a forceful 0.3x rate, it still takes 8 seconds to stop). You should consider subtracting a value from the speed instead of multiplying the speed with something. This creates a much more natural deceleration. The current curve is extremely exponential.

    Issue #5: Elasticity is hard-coded when dragging

    The current elasticity value only affects how a scroller hitting the end during a scroll is handled. It's completely ignored when you drag over the edges. Please see how Apple does this. They apportion about 20% of the pointer movement to dragging of the view, indicating a sluggishness. This value is hard-coded in UIElements, and is close to 100%, which does not feel like any other elasticity implementation.
     
    Protagonist, Cery_ and MousePods like this.
  2. MousePods

    MousePods

    Joined:
    Jul 19, 2012
    Posts:
    467
    I have also found and reported a few scrollview bugs. The only one I think I also found in your list is:

    Scrollview needs a ton of work. I hope its on the short list :(
     
  3. unity_griendeau

    unity_griendeau

    Unity Technologies

    Joined:
    Aug 25, 2020
    Posts:
    123
    Hi perholmes,

    Could you let us know on which version of the Editor you are? And the version of the UI Toolkit package if you are using it?

    Thank you!
     
  4. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    233
    Hi,

    I'm on 2021.2.0b7.3246. The built-in package version is just showing up as 1.0.0. But I've been asked this before, and I don't know if there's a more detailed version number somewhere else? It has been 1.0.0 for several editor betas.
     
  5. antoine-unity

    antoine-unity

    Unity Technologies

    Joined:
    Sep 10, 2015
    Posts:
    475
    This is kind of a placeholder version, the version to provide is the main Unity version like you did.
    Thank you.
     
  6. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    233
    The toughest of these issues is the velocity not being calculated correctly, because it's actually impossible to scroll to a place in a list and then tap on it. When you stop over the item you want to tap, it actually jumps out of view before you have a chance to click it. This means that it's not just cosmetic, it actually doesn't work, and I can't release anything to users in this state. So I hope you'll give this the highest priority.

    Also a heads up, scroll views interact poorly with the device simulator. After one good scroll, they routinely jump to random places or to the top of the list, or become unresponsive. I can't spot the pattern yet. It's only in the device simulator. In the regular game view or on actual devices, you don't have this randomness.

    I would suspect it's due to the tricks the device simulator does to manipulate coordinates to emulate resolutions, and UIElements using the true coordinates. In the latest device simulator, it's necessary to go via UnityEngine.Device.SystemInfo, and the other classes under UnityEngine.Device to get device info.
     
  7. Cery_

    Cery_

    Joined:
    Aug 17, 2012
    Posts:
    19
    +1
    For all of the mentioned points. The ScrollView behaviour has a lot of room for improvement. Besides the mentioned points I also reported two ScrollView related Bugs:

    • Having a rotated element inside a vertical ScrollView (regardless its shape and size) makes the ScrollView scroll horizontal.
    • Absolute positioned objects inside of ScrollViews expand the content field thus make the whole ScrollView scrollable even though absolute objects shouldn't influence the size of parent objects.
     
  8. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    233
    To be completely honest, we've been reimplementing all of this from scratch, and it's much, much nicer. I was going to post a video at some point, because it's kind of a pity if we're the only ones that use this, and maybe it should become an alternative UI control framework.

    The core issue is that all of what UI Elements provides is touch hostile. If what you're putting inside of the scroll view is a menu, or controls, you need a hand-off between the controls and the scroll view itself. For example, you press a menu item, but as you drag up and down, the menu item lets go of the mouse capture and hands it to the outer scroll view, which then starts scrolling. The same for check boxes, buttons, sliders, text edits. Every phone does this. You initially interact with the control, but if your interaction is too vertical, the scroll view gets the events instead.

    This is hard to do with the current UI Elements out of the box, because the controls and the scroll view aren't aware of each other. So we've basically made what we consider "proper" versions of everything, and the only Unity controls we use are labels and text edits. Everything else is made from scratch.

    And then for the scroll view, the Unity implementation of a scroll view is really poor. The whole flicking and rubberbanding and deceleration, is just not very pretty. Unity does deceleration with a multiplier so it continues forever after a steep braking, it can start moving after a pure press and release, and it just feels very homemade. Our scroll view has linear deceleration, rubberbanding, bounce, smooth scrolling with mouse wheel.

    Our scroll view also slides horizontally for submenus, so you have submenus exactly like on your phone.

    I'll post a video when I have time to make one. Since I was only building this for us, some things might be too custom for general use. But it gives us app menus that feel professional, and I'd hope to at least raise the bar.

    But for all the ranting, as a core HTML/CSS thing, UXML/USS works really well. I'm very happy how easy it is to build in it. What's bad is only that the Unity-provided controls are crummy, are full of weird behaviors and unstylable sub-components, and no rhyme or reason for how to access this. So we gave up.

    Here's a screenshot:

    upload_2021-9-27_16-10-1.png
     

    Attached Files:

    Protagonist likes this.
  9. perholmes

    perholmes

    Joined:
    Dec 29, 2017
    Posts:
    233
    And then same thing on a smaller device, the whole thing becomes scrollable, and the controls automatically arbitrate between interaction and letting the outer container scroll.

    upload_2021-9-27_16-13-18.png
     
    Protagonist likes this.
  10. Cery_

    Cery_

    Joined:
    Aug 17, 2012
    Posts:
    19
    I totally agree. Your UI looks awesome!
    Reimplementing seems to be the best method for now. In the past hour i was able to hack some of the functionality into the existing systems by making a copy of the original ScrollView from the disassembly and changing the necessary parts. Most of the weird flicking and slow scroll behaviour was just connected to the animation update set to fixed 30ms(?!) setting this to 60fps (16ms) solved most of the scroll speed/acceleration issues. Similarly clamping one axis and having one axis elastic was just a small change.

    If you could publish your system that would be awesome! Though I am guessing this is a lot of work. For now i can work with my hackish solutions until a better Unity implementation is published.

    The overall UI Toolkit is awesome. It's a total game changer but currently needs a lot of workarounds.

    Looking forward to further updates!
     
unityunity