10 ms·

Updating scrollTop is a pretty slow way to scroll on some browsers. Have you tried animating `transform`? That gets you hardware acceleration on webkit at least

nickporter 13y ago
+100 I can't believe nobody else mentioned this.
- snookca 13y ago
  Animating transform doesn't affect page scroll, which is a more useful use case (since users need to scroll a page) than being able to use a translate transformation. Of note, a translate transformation still isn't perfect. It seems to chug and then turn into a smooth animation.
  - anondesign 13y ago
    Eh, updating page at end/cancel easy enough. I use this approach to animate a page scroll: 1. Animate #transform using jquery's animate (which doesn't work out of the box unfortunately, you have to use a custom #step fn) 2. Install "capture" event handlers on document.body that will cancel the animation, reset scrollTop to the state of the transform, then reset the #translate to 0 on #scroll or #touch (so we don't "fight" the user scrolling) 3. .. animation runs, calls my "complete" callback which uninstalls the event handlers, sets #translate back to 0, and updates scrollTop. Unfortunately there is a noticeable "glitch" here if the user tries to immediately further interact with the page. #2 is optional (OP's implementation didn't handle canceling anyways). I'm sure there's a jquery plugin to do this and degrade to scrollTop on non-webkit browsers. Edit: formatting.
just2n 13y ago
Additionally, jQuery is not known for its performance, especially regarding animations. For me, on Chrome Canary, the animation "chugs" every 20-30 frames (from 60 fps to a frame that takes 200ms). It's almost entirely in rendering, and it's immediately following a jQuery callback. It only happens when scrolling down. I'd like to see this done with a very simplistic requestAnimationFrame tweener to compare the same type of animation against something that is doing nothing else but computing a new scrollTop and setting it. I have a strong feeling, in Chrome at least, that the problem here is jQuery, not SVG perf. Additionally, for other browsers, I'd like to see this tested with icon fonts.

nickporter 13y ago

+100 I can't believe nobody else mentioned this.

snookca 13y ago
Animating transform doesn't affect page scroll, which is a more useful use case (since users need to scroll a page) than being able to use a translate transformation. Of note, a translate transformation still isn't perfect. It seems to chug and then turn into a smooth animation.
- anondesign 13y ago
  Eh, updating page at end/cancel easy enough. I use this approach to animate a page scroll: 1. Animate #transform using jquery's animate (which doesn't work out of the box unfortunately, you have to use a custom #step fn) 2. Install "capture" event handlers on document.body that will cancel the animation, reset scrollTop to the state of the transform, then reset the #translate to 0 on #scroll or #touch (so we don't "fight" the user scrolling) 3. .. animation runs, calls my "complete" callback which uninstalls the event handlers, sets #translate back to 0, and updates scrollTop. Unfortunately there is a noticeable "glitch" here if the user tries to immediately further interact with the page. #2 is optional (OP's implementation didn't handle canceling anyways). I'm sure there's a jquery plugin to do this and degrade to scrollTop on non-webkit browsers. Edit: formatting.

just2n 13y ago

Additionally, jQuery is not known for its performance, especially regarding animations. For me, on Chrome Canary, the animation "chugs" every 20-30 frames (from 60 fps to a frame that takes 200ms). It's almost entirely in rendering, and it's immediately following a jQuery callback. It only happens when scrolling down. I'd like to see this done with a very simplistic requestAnimationFrame tweener to compare the same type of animation against something that is doing nothing else but computing a new scrollTop and setting it. I have a strong feeling, in Chrome at least, that the problem here is jQuery, not SVG perf. Additionally, for other browsers, I'd like to see this tested with icon fonts.