negative acceleration in scrollview

Solar2D General Questions/Discussion
#41

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:

#42

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?

#43

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!

#44

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:

#45

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!

#46

@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”).

#47

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.

#48

Yes that is the bit that needs changing IMHO.  I’m trying to get a “list of changes”.

There are three behaviours that should happen if a tableview (or scrollview) is being scrolled:

  1. touch with no finger movement should halt scrolling

  2. flick in direction of scroll should add momentum

  3. flick in opposite direction should reverse the scroll

  4. and 3. seem OK it is 2. that doesn’t work as other native apps do and that needs some work from Corona I think.

#49

You also asked for added acceleration on subsequent flicks, which is not there today, but I’m a little divided if that is neccessary.

What I’d like to see is more specialized widgets instead of these large ones which should contain every feature.

Even if not considering current swipe issues, the scroll quality itself is sub par, and in 2017 that is not good enough.

#50

i agree with both, scrollview and tableview needs a huge upgrade, lite version would be great and we could add ourselves more code if we need it, but the core base code should be smooth as butter, and right now, it is not.

sgs, the 3 behaviours a tableview should do are correct, but 2 and 3 are not scrolling correctly not only number 3 have problems. if you swipe really fast to scroll a huge amount of data…like an calendar (which is what i’m kinda of doing) swiping same direction or swiping opposite direction. sometimes will stop the scrolling, which fails completely the propose of fast swiping. if you do that in the google calendar it will work 100% of the times. no mather the speed or times you swipe it will always respond to your swipe. don’t know what project you want. any will have this problem. just copy and paste corona example and add 1000 items and test it. problem 2 and 3 will be there with the simplest tableview possible.

anaqim, didn’t understand what you want me to test. but you get what the problem is, so I’m not alone on this boat.

#51

anyone have a working version of an example with open source corona scrollView?

i found out that if you press the screen a little time on the same spot (±half a second or more) and try to swipe up or down it will move a little the scrollView then it will stop. it will not create that acceleration process. that doesn’t happen on google calender. i’m studying corona scrollView code, the code is pretty well made. i believe the math formula behind the movement can be improved. i wish i could “play” a little with some variables i have in mind.

the code i’m testing is:

local scrollView = widget.newScrollView( { top = 0, left = 0, width = display.contentWidth, height = display.contentHeight, scrollWidth = display.contentWidth, scrollHeight = display.contentHeight, listener = scrollListener } ) for i=1, 120 do local options={ text=" It's the end of the world as we know it and I feel fine.\n", width=display.contentWidth, y=i\*50, } local text=display.newText(options) text.anchorX=0 text.anchorY=0 text:setFillColor(0,0,0,1) scrollView:insert(text) end
#52

yeah I see the same behaviour in my app using tabelView, which is logical as they both use the required widget_momentumScrolling.

#53

though that is probably to prevent momentum scrolling when using the finger to move the scroll from one position to another, ie not flicking

#54

the formula is directly associated with the time you are pressing the finger (time you are pressing and the distance). if you press a long time and move you will fail all the time the scroll.

they didn’t have in account that you can have a still press and move it. old people or babies tend to do that more offen. usually people that are not good with technology.  i remembered i had this problem on my scroll menu code and had to correct it. I guess Corona never thought about it. Google scroll doesn’t have this problem also.

#55

youre right, the more modern way to do it is to stop scroll momentum with a touch.