6 ms·

Extremely impressive demo. This is how a Show HN for a front-end library should always be: take me straight to a demo of the coolest part. What exactly makes

by habosa 12y ago

Extremely impressive demo. This is how a Show HN for a front-end library should always be: take me straight to a demo of the coolest part. What exactly makes this so fast? I'm not familiar enough with JS/CSS to know from the code. The 200-element sticks demo was by far the smoothest animation I have ever seen for that many elements.

yesimahuman 12y ago
Translation, rotation, scale, and opacity are the fastest things to animate in the browser. The GPU can be employed and the browser does not need to recompute layouts and reflow. Doesn't work for everything (without building layout systems in JS), but can be used for quite a lot of animations.
mattdesl 12y ago
JS animations are inherently very fast, most likely because you're running a modern browser. :) The code is basically just computing a 4x4 matrix for each card per frame built up from some tweened position/rotation/etc. Then it applies the matrix to the element's CSS. The code doesn't look optimized (ie allocates lots of typed arrays) but as the demo proves, its already pretty fast.
- deleted 12y ago
  [deleted]
- Kiro 12y ago
  > allocates lots of typed arrays Out of curiosity, can you show an example and how it should be done properly?
  - mattdesl 12y ago
    A better approach is to re-use arrays instead of creating intermediate ones, which is what gl-matrix[1] advocates. Each tween might still need its own matrix instance for start and end points, but at least these are not created per tick. A similar approach is to use a "pool" of arrays[2] which allows you to re-use them without having to manually keep track of the temporary arrays. [1] - https://github.com/toji/gl-matrix https://github.com/toji/gl-matrix [2] - https://github.com/mikolalysenko/typedarray-pool https://github.com/mikolalysenko/typedarray-pool
    - deleted 12y ago
      [deleted]
  - yesimahuman 12y ago
    Similarly, PhysicsJS employs a "scratchpad" of pre-initialized vectors for fast intermediate computations. That way you aren't constructing new objects, but grabbing a free one, zeroing it, and using it as you would before. Seems quite performant. https://github.com/wellcaffeinated/PhysicsJS/blob/master/src/util/scratchpad.js https://github.com/wellcaffeinated/PhysicsJS/blob/master/src...
leeoniya 12y ago
what makes is fast is the use of requestAnimationFrame [1] (rather than setTimeout or setInterval) that exists in all modern browsers and simply applying css, letting the browser handle and GPU-accelerate as it sees fit. the only thing the js does is compute the matrices for each step/frame in fixed-length typed arrays. [1] https://github.com/daniel-lundin/snabbt.js/blob/master/src/main.js#L214 https://github.com/daniel-lundin/snabbt.js/blob/master/src/m...

by habosa 12y ago

yesimahuman 12y ago

Translation, rotation, scale, and opacity are the fastest things to animate in the browser. The GPU can be employed and the browser does not need to recompute layouts and reflow. Doesn't work for everything (without building layout systems in JS), but can be used for quite a lot of animations.

mattdesl 12y ago

JS animations are inherently very fast, most likely because you're running a modern browser. :) The code is basically just computing a 4x4 matrix for each card per frame built up from some tweened position/rotation/etc. Then it applies the matrix to the element's CSS. The code doesn't look optimized (ie allocates lots of typed arrays) but as the demo proves, its already pretty fast.

deleted 12y ago
[deleted]
Kiro 12y ago
> allocates lots of typed arrays Out of curiosity, can you show an example and how it should be done properly?
- mattdesl 12y ago
  A better approach is to re-use arrays instead of creating intermediate ones, which is what gl-matrix[1] advocates. Each tween might still need its own matrix instance for start and end points, but at least these are not created per tick. A similar approach is to use a "pool" of arrays[2] which allows you to re-use them without having to manually keep track of the temporary arrays. [1] - https://github.com/toji/gl-matrix https://github.com/toji/gl-matrix [2] - https://github.com/mikolalysenko/typedarray-pool https://github.com/mikolalysenko/typedarray-pool
  - deleted 12y ago
    [deleted]
- yesimahuman 12y ago
  Similarly, PhysicsJS employs a "scratchpad" of pre-initialized vectors for fast intermediate computations. That way you aren't constructing new objects, but grabbing a free one, zeroing it, and using it as you would before. Seems quite performant. https://github.com/wellcaffeinated/PhysicsJS/blob/master/src/util/scratchpad.js https://github.com/wellcaffeinated/PhysicsJS/blob/master/src...

leeoniya 12y ago

what makes is fast is the use of requestAnimationFrame [1] (rather than setTimeout or setInterval) that exists in all modern browsers and simply applying css, letting the browser handle and GPU-accelerate as it sees fit. the only thing the js does is compute the matrices for each step/frame in fixed-length typed arrays. [1] https://github.com/daniel-lundin/snabbt.js/blob/master/src/main.js#L214 https://github.com/daniel-lundin/snabbt.js/blob/master/src/m...