jjkaufman / wiv.js Goto Github PK

the animateLines function needs to be refactored to better support the new vue and react components

animateLines should be adjusted to only draw a single canvas (no more loop). It will take the canvas and the animation properties in as parameters.

“here’s a canvas, do quik mafs on it”

via pavlovscat on hackernews

move these things into initWiv() and cache them:
var speed = parseFloat(wivCurve.parentNode.dataset.wivSpeed)
var height = parseFloat(wivCurve.parentNode.dataset.wivHeight)
var tightness = parseFloat(wivCurve.parentNode.dataset.wivTightness)
var thickness = parseFloat(wivCurve.parentNode.dataset.wivThickness)
var ctx = wivCurve.getContext("2d");
do this once on init, the canvas context remembers it anyway:
ctx.strokeStyle = wivCurve.parentNode.dataset.wivColor != undefined ? wivCurve.parentNode.dataset.wivColor : "#FF0000"
don't convert numbers and strings all the time, use numbers and init them to 0
//current frame is tracked on per wiv basis. This is to help with speed calculations
if (parseFloat(wivCurve.dataset.count) > 100000) {
wivCurve.dataset.count = "0";
}
wivCurve.dataset.count = (wivCurve.dataset.count ? parseFloat(wivCurve.dataset.count) : 0) + speed;
parseFloat(wivCurve.dataset.count) also is used a lot in that loop.
And don't set unneccessary canvas state, this should happen only once per draw loop iteration: [edit, actually, as I said above, the canvas contexts remember it individually, so do this once in initWiv(), and not in the draw loop at all, yay!]

ctx.lineWidth = thickness;

That's all just at first glance, but I bet you, this would help with slow laptops and whatnot :) Such "small" things really add up when you do them 60 times per second * number of borders. I don't know if setting the canvas width or height to the value it has anyway to clear it (instead of clearing/drawing a rectangle explicitly) is still a useful thing to do, but you might try that as well.

We should add a new data attribute (like data-wiv-css-match or something) that contains a CSS selector string. During the animation loop, we should check if the wiv in question matches said CSS selector, and only do the animation if it does. This would allow library users to dynamically start/stop wiggling in a variety of ways.

Because we use requestAnimationFrame to render each stage of the animation, our FPS is dependent on individual browsers. Since wiv speed is determined by calculations done within the function called by requestAnimationFrame, a slower FPS results in not just choppier animation but also a slower wiv speed.

We could remedy this by calculating the frame offset (which defines our speed) outside of the animation function at a set rate, and referencing that calculation from within the animating code.

We could potentially make significant performance savings by ignoring wivs that are outside the browser's current view.

The way image wivs are currently implemented the images appear to bounce. Images that ride the wave could be achieved with frame + direction arithmetic

Right now, everything that wiv.js does is in one file. As we add features, that file grows more and more unwieldy, and likely intimidating to any community devs who may wish to contribute to the liberation of divs. We should make an effort to factor out logic and settings into discrete files where it makes sense to do so.

This is likely something like (height * 2) + (thickness * 2).

Once calculated, this figure should be used for the wiv padding, as well as the corner intersection calculation and anywhere else we're already approximating it.

Support images along the wiv for extra wiggle factor.

data-wiv-image-url
data-wiv-image-style
data-wiv-image-frequency

For performance, data attributes are only read at time of initialization and cached in a javascript object. This is a problem for when a feature requires adjusting the attributes on the fly. For example: speeding up the wiggle on hover.

Unfortunately, it doesn't look like javascript has an event for data attribute changed.

Perhaps a refresh function to refresh the cache with the data attributes values?

The top left and bottom right corner have flickering with the new intersection logic.

I think line thickness may be the problem

Have an idea to reduce jumpiness of wiv animation on the extreme examples.

I think many intersection points exist. Will try to find the intersection point with the min distance with the last intersection point

This is an issue with JS's aggressive falsyness. The fix will be to fall back to standard speed only if the given speed is not a number.

Currently the intersection of wiggles is approximated and a straight "lineTo" connects the wiggles. Ideally, the true wiggle intersection can be calculated and the lineTo can be eliminated.

Currently, npm install will not work on windows.

https://github.com/isaacs/rimraf could be used and eliminate the need to use rm