-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Safari sometimes interrupts trackpad scrolling during fast swipes #160
Comments
Same here, also on latest Chrome ( |
Hi @martinpesout, @vincent-io, I'm not able to reproduce what you describe. (Scrolling is fast for me in Safari, even with 10k rows.) I have however noticed an occasional issue with Safari that might be what you're seeing (not sure?). Basically if I quickly swipe up or down on the track pad while also swiping a little to the right or left (usually by accident) it causes the scroll animation to come to a sudden stop. This doesn't happen with a mouse wheel (obviously) or with the scrollbar. Only with the track pad. Could this be what you're seeing? |
I did a few tests and this is probably source of this problem. Is there any locking of scrolling when you swipe to the side? Maybe increasing detection limit for swiping to the sides can solve this situation? If I swipe down and just a bit to the left, scrolling suddenly stops. When I repeat this situation a many times (swipe down and just a bit to the left), I have to wait a while because in that moment I'm not able to scroll down without animated scrolling (it looks that this scrolling animation is being stopped). After while problem is gone and I can continue swiping down with animated scrolling. This problem really doesn't happen with a mouse wheel. |
Yes, this could very well be the problem. Hard to be 100% sure, as I can't see if I'm actually swiping sideways, but considering the sensitivity of the trackpad this is very plausible. This is much easier to reproduce on Safari than on Chrome by the way. |
Agreed. I've only observed this on Safari. Anecdotally I've only observed it while swiping really quickly too. Slow swipes are fine. And slow swipes that build to really fast swipes are always fine. Starting from a dead stop and swiping quickly sometimes causes the problem though.
I'm not locking or manually managing scrolling at all. I'm just reacting to scroll events by querying the updated/new |
+1 This exactly describes the behaviour I'm experiencing. |
This is a behavior that's been around for at least a month for what it's worth. And I'd love to fix it but I don't have any ideas currently. Would welcome ideas if you guys think of any. :) |
Thanks for your response. Keep this issue open, I'll try to find some solution in next 14 days. |
Thanks @olivierandriessen :) One more data point that may be worth mentioning is that I am unable to reproduce this behavior (or at least much less frequently) using Safari Technology Preview than vanilla Safari. Seems like STP behaves more consistently with Chrome and Firefox. |
@bvaughn Thanks for mentioning, sounds this problem will resolve itself in the near future then. I might leave it for now and test tomorrow in STP too. |
That's interesting insight guys. I confirm that I also don't have this problem in Safari Technology Preview. So if I understand STP well, we should expect the same behavior in Safari in the future, right? |
@martinpesout Although the it can still change I think we can expect that the behavior will be the same in the next version. |
One thing to note is that the issue in Safari only arises when inertial scrolling sets in (where the scrolling continues a bit and then gradually comes to a halt when you lift your fingers off the trackpad). So moving with fingers letting go is the problem, moving stopping then letting go not. |
By caching all the elements being rendered and implementing shouldComponentUpdate I could bring down the time it took to render the grid from approx. 6ms to 0.1-0.6ms, so definitely recommend doing that. I almost notice no lag in STP now. |
Very interesting @olivierandriessen. I have an open issue (#162) and an ongoing branch (batch-rendering) where I've been experimenting with reducing the number of times I render as well as caching rendered cells. It doesn't quite work right yet though (eg. scroll-to-index is broken) and I haven't had time to dig into deeper it yet. I'm also vaguely concerned about caching cells having an unexpected impact on the way people are already using virtualized. Not sure there. Maybe I could make it something that could be enabled/disabled... |
Hi @bvaughn, thanks for the project! I'm testing FlexTable component. In Chrome it looks smooth, but uses more CPU after update. |
@superlaziness Which version are you comparing 6.1.1 to? (It "uses more CPU" than which version?) |
@bvaughn with 6.0.4 |
Hm. So the only things that changed between those versions were aria-related (usability) features in the 6.0.x range and the |
Oops, sorry. I also updated the React to 15.0.1. This may be because of this. |
That would be good to know! I'm moving today so I'm pretty swamped. (Just taking a break from loading up the truck.) If you get the chance to compare performance with 6.1.1 and React 0.14 vs 15 - let me know? |
Ok. I made some measurements. There is no difference between v.6.1.1 and 6.0.4.
|
Are you measuring production builds? |
My goodness, Dan. You're almost creepy fast. :) |
@Gaeron no I measured it with Perf on dev builds. |
But I've just made some tests on production builds: 11ms on 0.14.6 vs. 24ms on 15.0.1 |
Anyway, I can't see any visual difference between versions in Chrome. And it is not usable in Safari on both of versions yet. And yes, those wiggles only visible when you use trackpad with inertial scroll. |
Could you clarify what you mean by this @superlaziness? Aside from occasionally interruption of fast scrolling (for reasons described above) react-virtualized works fine for me in Safari with both React 0.14 and 15.0. (I do notice a bit of the jitter you mention above for React 15 dev build though.) |
This is clearly seen on gif I attached above. @olivierandriessen described the same issue. When you scroll with trackpad and then lift your fingers off, Safari continues to scroll grid with inertia. At this time, the grid starts to twitch. It looks really bad :( I'll test it in STP tomorrow. |
@superlaziness Currently I'm managing to keep the user experience acceptable by keeping the render times as low as possible. |
I guess I found something in componentDidUpdate method:
This block updates scroll position to one from state. State's scrollTop contains value from previous animation frame (_setNextState method). By assigning old scroll value it returns scroll several pixels back and we see those twitches. Without this block inertial scroll doesn't work in Safari. |
@olivierandriessen yes, this also should be part of the solution. Can you show your workaround? |
Great observation @superlaziness. I've been focusing my free time efforts on the branch for #182 but I'll try to play around a bit with what you've pointed out. Maybe I can drop the animation-frame loop without negatively impacting performance? In previous testing, I've anecdotally observed that it usually doesn't have much of an impact. |
I forgot to tell that I made a quick-duct-tape-fix for this problem: |
Doesn't that assume that scrolling is always in the downward direction (and at a constant rate)? |
Nope! It shifts scroll by one pixel than expected. That is allow browser to continue scroll animation. And 1px shift is actually invisible. |
Hm. I'm wary of that approach because of its potential impact for issues like #2 and also because of its potential impact on things like 1pixel borders. It's interesting to note though (eg. if you had a top border of 1 pixel you would never be able to see it with this patch). I don't have the bandwidth to dive back into scrolling issues at the moment so I'm going to leave this sit for a while. We'll see if others have insight. :) |
Safari 9.1- I'm specifically testing with 9.1 (11601.5.17.1)- seems to have improved this issue. I can still reproduce it but it works better than Safari 9.0 did. |
Also having this issue, just updated from 7.6.0 -> 7.8.1 and the issue looks to have been getting worse. Will also test using the tech preview. Chrome works fine. Amazing work btw, love the lib! I'm on safari 9.1.1 btw. |
Hey @jfrolich, Yeah, the issue is still around for Safari. I actually tested it just earlier this morning to see if an update had fixed it yet (since it's fixed in Safari Technology Preview for some time now). I'd be surprised if the issue got any worse from 7.6 to 7.8 to be honest. I think it's just the sort of thing that's sometimes easy to reproduce and sometimes harder. Thanks for the compliment on the lib! :) |
@jfrolich, if you also have updated to React 15.x, try to run it in production. |
Hard to overstate the different between Prod and Dev for React 15 yeah |
@superlaziness: I run it in production. Probably indeed it just looked worse, do not have any data :) |
I am closing this issue because I have no planned course of action to take. It seems to impact only Safari and it seems to have been fixed in the Safari Tech Preview. There's some good discussion in this thread ^ and I'll happily discuss anything ongoing with folks on the thread if anything new develops. For the moment though it seems like there's not much to do (that I'm aware of) other than wait for a Safari update. |
I'm also having this same issue, and using Safari Tech Preview hasn't solved it. It improves performance, but the list is still unusably janky. This seems to indicate the problem won't be fixed by a Safari update. In light of this, what should we do? fwiw, I've done some performance profiles in-browser, and it seems the problem is related to JS computation within React, rather than repaints/reflows. I've dived into the code a bit, done some testing with |
@mtchllbrrn What browser are you seeing "unusably janky" performance on? Which react and react-virtualized versions? Are you sure you're running React in production mode (minified JS from CDN)? Safari Tech Preview performs pretty flawlessly for me every time I've tested it. It's on-par with Chrome and Firefox. I have never once seen the interrupted scroll issue there. Scrolling "jankiness" is different. I'm also not seeing that- but I want to point out that that's not what this issue is about. :D |
After reading some of the previous posts more carefully, I see now that my issue might be something different. The problem I'm seeing is a twitching behavior, and it occurs even when my fingers are on the trackpad (unlike the issue discussed above). Maybe this gif will help: https://cl.ly/0d0B1k1E3W1F It's difficult to see here due to the framerate limitations on the gif, but if you look at the scrollbar, you'll see that it jitters within the first few seconds . This is the problem I'm having, and it occurs in both Safari and Safari Tech Preview. fwiw, React is in production mode, and I'm using the latest version of react-virtualized. If you like, I could try to put together an example repo that demonstrates the problem and open another issue for it. |
Hm. I see it! Can you share this with me so I can run it? Don't think it's related to this issue. |
@mtchllbrrn: Same here. Happens in both current safari and tech preview. |
I see one problem in Safari browser (9.0.3) on my Macbook. I'm trying this example https://bvaughn.github.io/react-virtualized/ with 10000 of rows. If I try to scroll quickly using touchpad, I'll see that from some time is smooth elastic scrolling gone and everything became really choppy.
It looks like there is triggered some event which prevents scrolling.
The text was updated successfully, but these errors were encountered: