negative acceleration in scrollview

Solar2D General Questions/Discussion
#1

anyone notice any negative acceleration in scrollView?

what i mean is if you scroll real fast on a small time of space it will scroll some pixels (very few) and then stop or even go back 1 or 2 pixels or will simply ignore the touch i’ve made.

this only happens if you scroll real fast. i have a client crying about it. he doesn’t like the scroll when he scrolls fast. so my only solution is creating myself a new scrollview or trying to resolve here.

i think this could happen since the acceleration is exponential so it could reach the max, passing it going back to negative value. i’ve made a scroll menu some time ago from scratch with my own formulas and i limited the max speed so i didn’t have this problem.

I tried changing friction but with no success. what variables I’ve access to so i can try to resolve myself? can i access max speed so i could limit it?

any ideas? 

thanks in advance.

regards,

Carlos.

#2

Hi again,

the only thing i can think of (since I am working with scrollView myself these days, is that the view contain some element that makes it longer or wider and that can make it “snap back” a little. I found that text objects are more likely to do this if you specify text height.

scrolling really fast isnt, from what I see, possible unless you change core script parameters.

#3

thanks anaqim, for your input,

i’m testing right now myself the output values of the scrollview, and discovering that it is real the negative acceleration.

printing this 2 variables

print(scrollView.\_view.\_velocity, scrollView.\_view.\_lastTime)

ive this result:

16:51:28.603  Scroll view was touched

16:51:28.603  0 8643.1

16:51:28.603  ____________

16:51:28.603  0 8643.1

16:51:28.603  ____________

16:51:28.613  0 8643.1

16:51:28.613  ____________

16:51:28.623  0 8643.1

16:51:28.623  ____________

16:51:28.633  -0.080033281166426 8643.1

16:51:28.633  ____________

16:51:28.644  -0.080033281166426 8643.1

16:51:28.644  ____________

16:51:28.644  -0.080033281166426 8643.1

16:51:28.644  ____________

16:51:28.644  0.080033281166426 10118.1

16:51:28.644  Scroll view was released

16:51:28.644  ____________

16:51:29.548  Scroll view was touched

16:51:29.548  0 10986.5

16:51:29.548  ____________

16:51:29.548  0 10986.5

16:51:29.548  ____________

16:51:29.559  -0.067802182464593 10986.5

16:51:29.559  ____________

16:51:29.570  -0.067802182464593 10986.5

16:51:29.570  ____________

16:51:29.580  -0.067802182464593 10986.5

16:51:29.580  ____________

16:51:29.580  -1.5 10986.5

16:51:29.580  ____________

16:51:29.590  -1.5 10986.5

16:51:29.590  ____________

16:51:29.590  -1.5 11062.2

16:51:29.590  Scroll view was released

16:51:29.590  ____________

16:51:29.621  ____________

16:51:30.043  ____________

16:51:30.366  Scroll view was touched

16:51:30.366  0 11096.3

16:51:30.366  ____________

16:51:30.377  0 11096.3

16:51:30.377  ____________

16:51:30.387  0 11096.3

16:51:30.387  ____________

16:51:30.387  0 11096.3

16:51:30.387  ____________

16:51:30.397  0 11096.3

16:51:30.397  ____________

16:51:30.407  -1.5 11096.3

16:51:30.407  ____________

16:51:30.418  -1.5 11096.3

16:51:30.418  ____________

16:51:30.418  -1.5 11096.3

16:51:30.418  ____________

16:51:30.428  -1.5 11096.3

16:51:30.428  ____________

16:51:30.438  -1.5 11096.3

16:51:30.438  ____________

16:51:30.448  1.5 11096.3

16:51:30.448  ____________

16:51:30.448  1.5 11918.2

16:51:30.448  Scroll view was released

16:51:30.448  ____________

16:51:31.079  ____________

16:51:31.445  Scroll view was touched

16:51:31.445  0 12550.7

16:51:31.445  ____________

16:51:31.456  0 12550.7

16:51:31.456  ____________

16:51:31.466  0 12550.7

16:51:31.466  ____________

16:51:31.466  0 12550.7

16:51:31.466  ____________

16:51:31.477  -0.0063262313590543 12550.7

16:51:31.477  ____________

16:51:31.487  -0.0063262313590543 12550.7

16:51:31.487  ____________

16:51:31.487  -0.0063262313590543 12958.2

16:51:31.487  Scroll view was released

the last touch he didn’t make a move and the variable “scrollView._view._lastTime” is the highest. on all the other touches the higher the last time is higher the velocity with the -1.5 limit. but when it passed a limit the speed gone to almost 0.

EDIT: “_lastTime” gives me always incremental value, so wrong variable to test here…back to try other variables (testing _delta right now)

#4

i tried to scroll like there is no tomorrow on my app but I dont get any slap back behaviour.

I’d make a brand new project and a default scrollView to check if this applies only to your specific apps scroll, or not.

Nothing quite like playing bug detective, is it?  :wink:

#5

hehe, thanks for you help. but don’t look for a slap back. it’s more than a stop when it should scroll in the max velocite. some times before that stop it goes back a pixel or 2. but the real problem is swipping fast and the scroll moves while your finger is down and stops when you release. it should go at max speed. in simulator is very hard to do this. on device on ipad is very easy to do this.

#6

what it seems is that corona limited the velocity (_maxVelocity) and didn’t limit the acceleration (i could not find this variable).

if they did not limit this function and just made an exponential formula things can go wrong.

#7

oh yeah i know what you mean, like a fast swipe simply failing like its too fast for the code, easy to recreate.

I’m testing on a samsung pad :slight_smile:

i suspect this is because of the underlying code requiring a certain time window to calculate distance vs time, and that the swipe is just too fast for the code. The only solution would be to shorten that required time window, but thats going to the widget script and beyond my lua skills.

I have created my own scrolling code when i was coding a little in game maker pro, since they dont have a scroll widget or function. Took me a nasty 3-4 weeks to get it working well so yeah the mechanics behind is known.

If I recall right, I think the calculation windows was optimal at somewhere beyween 4 and 6 ms when running at 60 fps. if only 1 or 2 ms off, i’d get this kind of behaviour under extreme swiping conditions.

#8

yes, anaqim exactly that.

the one scroll menu i’ve made took me more than a week also to build from scratch, so i know the pain is to create a new one. it would be better if we could solve it with the existing code (scrollView).

edit: the problem can’t be in “just to fast for the code”, because my scroll menu does not have this problem. and is the same client i’m making this new app and he wants a “feel” like the other.

if you print the variables while you swipe, you know the system is registering them because it shows those variables. my wonder is that since like you said distance vs time gives a huge result that is higher than the max int value. in that case it will give a negative score and the result is this.

side note: the first time i found a max int problem was playing tetris back in the days, when i played more than i should, and broke the 32768 limit and went to -32767…still didn’t gave up and went again to 32xxx and stoped there :wink:

#9

guess I will have to build myself a new scrollView…

#10

Hey carlos,

To my big embarrasment I just discovered that newTableView will do all i need it to do.

Rob made a decent tutorial on it as well.

If you are making a vertical scroll, this might work for you.

It is highly configurable and has a maxVelocity parameter too.

https://coronalabs.com/blog/2014/03/04/tutorial-advanced-tableview-tactics/

#11

thanks anaqim for the input,

I went to scrollView to evade the slow code of tableview (it creates and deletes a lot. I don’t need that in this project). I used a lot of tableviews but had more problems with it than what it supposed to do, I gave up on them in most of the cases. I still use them time to time. it has a lot of features I don’t need in simple scrolls, it’s overkill. that’s why scrollView exist. I went to a simple scrollview with all my items, but even that I guess I cant use because of this problem (negative acceleration).

I’ve more than 100 self-made functions that help me on my daily base code, one more won’t hurt.

I just keep being frustrated with half baked functions corona provide. vibration function is another joke function…well let’s move on. crying about it won’t solve the problem. I’m old school I’m used to heavy labor. I’m from the time to do a simple append on a string we had to build 5 line code (or more), now is just “…” and done. I can’t complain about that.

regards,

Carlos.

#12

hi again, damn now you got me worried about the performance.

i am considering a move to B4A but am a little on the fence as its a give and take as always

#13

HI Carlos,

I just implemented it in my app, and it works perfectly on my mid end android device.

Maybe my list is less complicated than yours. On screen is shows up to 25 rows and each row has 3 elements, including an image.

Wont be moving on after all then  :) 

#14

good to know it works for you.

if you scroll fast like I told you to do with scrollviews, it will have the same effect, it will stop sometimes like it did not register the finger.

my scrollview is very very simple. the problem is not how many elements the scrollview/tableview have…it’s how the core was implemented when we move the finger. it fails when it’s “too fast”.

i’ve a htc u11, and google calendar which has parallax it runs butter smooth all the time no matter how fast I press and move the finger up and down.

if i try the same thing in a simple scrollview or tableview it will fail miserable, failing more than 50% the fast swipes. if I go slow with the finger it will respond right. but the devices are getting faster and people are swiping faster. we can’t do that with tableview or scrollview, so more 2 APIs that I can’t use. the client had an iPad mini 2 never bother me with that problem, now he bought a new iPad pro, he wants to show their clients how fast it is the device and his app and he can’t do it because it will stutter or miss most of the swipes. there should not be a “right” way to swipe. any should swipe the way he wants and the scroll should respond to that. it’s impossible with scrollviews/tableview.

tableview have the problem also of micro stuttering. that’s because of the delete/create cycle while scrolling. I resolve that using graphics.newTexture() but I can’t use in all cases (large tables with lots of images).

but if you are happy with it good for you really :slight_smile:

#15

i agree its not perfect and if we flip the screen really fast it wont “get it”.

havent seen any micro stuttering yet and i also have some images that get “painted” as they arrive async from the net.

lowering friction and increasing maxVelocity does improve the experience some for me, but if your client is unhappy, that all that matters.

i am very curious how this “time-window” as I like to call it, is measures in the code.

If I was more proficient in lua I’d dive in and take a look. 

perhaps someone from staff can give us a hint as to how this is measured, unless you know this already?

#16

Guys I am curious to see your issues.  

I use scrollview (customised) and tableview and I do not experience the problems you are describing.  Now bear in mind I have an install base of over 2 million and not one single player has ever complained.

With tableview I can scroll 30-odd rows per second and one fast flick can scroll maybe 60-80 rows until momentum stops.  In my case each row has a graphic, 4 text fields and a button.

If your app is 30fps then code runs at 33ms if 60fps then code runs at 16ms.  There is no way you can flick faster than 16ms!

#17

sgs, it’s not the number of scrolls you can have per second, it’s how many of them are misses and hits. if you fast swipe up and down multiple of times, most of them are going to be misses in corona tableview or scrollview, thats a fact. if you do that in any of google apps or an android device you will notice a big difference, at least I did. but then again, I’m used to having nitpicked clients. I just installed your game, and your ranking scroll has that problem. it’s not a critical part of your project and I don’t see why any would criticize that. only if you know about the problem, and are looking for it, you will notice. unfortunately, my client notices that problem and wants to be resolved.

regarding of micro stuttering. that’s another fact, you will notice more with tableviews with photos. I saw that micro stuttering in other apps out there also, and i don’t see people complaining about it. that doesn’t mean is not there. but I see apps that are butter smooth also and Corona tableview is not one of them.

ps. your game is very nice. it has a lot of work on it. it reminds me sim city 2000, which i spent lot’s of hours/days/weeks playing it :wink:

#18

Hi Sphere,

I’ve identified 3 issues with tableView.

The first is what Carlos have found and reported, that when swiping too fast, the code does not catch the speed correctly.

With 60 fps there is a lower cap of 16 ms, but lets face it, noone can swipe of flick that fast.

However, to calculate distance and speed you need not only a touch event but also a release event.

That means the absolute minimum swipe detection windows is 32ms, which is still very fast.

Since this reported behaviour is easily repeated I will go out on a limb and say the current code detection window is larger.

I do not know how large it is in the tableView code, but through own tests of old i found that a detection window of 3-6 frames works well.

The second issue is one where i found that inserting rows on the fly would make it stutter a bit when also downloading image from the net. I’ve since tested my code on a much faster internet connection and I am not so sure this is a real issue, other than my home internet speed. The reason why it was hard to detect brings me to issue number 3…

Scroll performance stutters slightly when compared to other native apps scrolling.

There is always the possible issue of monitor refresh rates but I am using a monitor with gsync which makes it perfectly frame synced. I also invoked a long scroll with friction 1 and maxVelocity 1 on a very fast internet connection.

Looking at it moving at constant slow speed further confirms the issue.

The tableView widget has 1814 lines of code. I understand that this also includes using categories that stick at the top and a scrollbar. Perhaps a simpler widget for simple scrolling would help. scrollView scrolls smoother and has 861 lines of code. Both require momentumScrolling and widget adding another 1351 code lines. I dont know how much code quantity impact performance since I am too new to this, but it seems like a lot of code to achieve scrolling.

As I am writing this, I took a pause to check out the code of the widget.momentumScrolling to see if I could find out how velocity is calculated. Code lines 622-663 seem to do that, and from what i gather the code samples the time between each frame, bringing us down to the 32ms window if running 60fps.

That is a really small window! Sometimes when we swipe, be it continous or quickly, it is not always easy to maintain max swipe speed the last 16 to 32 ms before removing the finger from the screen. It can cause what is experienced as a sudden stop.

I will test this myself at home as I have no android touch device in the office, but what I suggest is to count an average speed of a slightly larger number of frames, and check how it behaves (Carlos?)

Cheers!

#19

@carlos, thank you!  Yes it has been a silly amount of work.  I grew up with SC2K and that was my inspiration (as there were no decent city builders similar).

I have seen that results with tableview can be a bit erratic and sometimes momentum can get confused with multiple flicks.  If scrolling up and you add another flick up then it should increase the velocity of the scroll.  Occasionally this doesn’t happen and seems to reset the scrolling parameters to the new touch points.  Is this what you are referring to?

IMHO, the widgets library needs a ground up rework because some of the code is years old and there are some strange code decisions in there - like stopping scroll if adding items on scrollview.

I agree with a tableview-lite that removes the categories and who uses scroll bars on mobile?  It would be great if it could also support horizontal scrolling.

If you can come up with a simple test project (without any network fetches per row) then maybe I can try get some resources at Corona for this but there is some resistance on changing widgets (as they are “good enough”).

#20

Im a bit confused who you are asking what sgs, but it looks like the momentum code resets on the touch began event, so not possible to add speed by further flicks.