search

notree-md / notree

Share your knowledge
MIT License
2 stars 1 forks source link

On-hover animation for node and link colors #19

Closed mpryor closed 1 year ago

mpryor commented 1 year ago

Starting a draft PR to play around with some animation concepts

mpryor commented 1 year ago

@jollyjerr Yeah for sure!! I've been wondering about how we want to handle our core-update loop in general. The only reason this even animates after the simulation is done is because I added that random setInterval() in, which may not be ideal.

Some things to think about:

  1. Do we want to just have a statically defined refresh interval? (Probably 1/60, for example), and just consistently call re-renders on that interval?
  2. Or do we want a dynamic delta between frames based off the elapsed time from the previous frame?
  3. Do we only want to call redraws when things are worth redrawing? For example, if there's no simulation running, no animations running, and no user events (hover, click, etc) it might be silly to be redrawing the canvas
mpryor commented 1 year ago

In https://github.com/jollyjerr/mindgraph/pull/19/commits/f1ff1b77d5cb1809f9cd51e78f4a9fcdc5baf391 I fixed the easing functions so they actually work now, added a couple more easing functions, and added an example page at http://localhost:5173/tests/animexample.html

jollyjerr commented 1 year ago

IMHO pinning the whole thing to 60fps or https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame would be fine for now!

mpryor commented 1 year ago

I updated the core rendering loop to use the window.requestAnimationFrame() per your suggestion. I also worked my way through Mozilla's Canvas tutorial, and this seems to be the preferred method for animations.

Now that the rendering loop is controlled on an interval (outside the Artist class), any re-renders that were triggered internally have been removed (during zoom, during mouseover events, etc).

With these changes, the animation stuff is pretty snappy