Feat: add redrawcomplete event

[brian-byassee]

Short description

Currently the redraw event firers before renderHead and renderTail have completed. This adds a new event redrawcomplete that fires once both head and tail have completed rendering.

In longer files redrawcomplete can take awhile to fire so we left redraw and redrawcomplete as two separate events

Resolves #

Implementation details

How to test it

1. Navigate to zoom example
2. Add: ['zoom', 'redraw', 'redrawcomplete'].forEach((e) => wavesurfer.on(e, () => console.log(Date.now(), e)))
3. view console

Screenshots

Checklist

• This PR is covered by e2e tests
• It introduces no breaking API changes

[brian-byassee]

Not certain how you feel about the new event names but happy to update them if you want.

[katspaugh]

I'm thinking, maybe this could be refactored into a promise, smth like:

    // Draw the waveform in viewport chunks, each with a delay
    return Promise.all([
      new Promise((resolve) => {
        const headDelay = this.createDelay()
        const renderHead = (fromIndex: number, toIndex: number) => {
          draw(fromIndex, toIndex)
          if (fromIndex > 0) {
            headDelay(() => {
              renderHead(fromIndex - viewportLen, toIndex - viewportLen)
            })
          } else {
            resolve(true)
          }
        }
        renderHead(start, end)
      }),

      new Promise((resolve) => {
        if (end >= len) {
          resolve(true)
          return
        }
        const tailDelay = this.createDelay()
        const renderTail = (fromIndex: number, toIndex: number) => {
          draw(fromIndex, toIndex)
          if (toIndex < len) {
            tailDelay(() => {
              renderTail(fromIndex + viewportLen, toIndex + viewportLen)
            })
          } else {
            resolve(true)
          }
        }
        renderTail(end, end + viewportLen)
      }),
    ])

I would also refactor those recursive timeouts into sequenced promises, but that's outside of the scope of this PR, I'll do it myself later.

[jason-whitted]

@katspaugh We thought about that, too; however, one downside to this is that createDelay could end up canceling the setTimeout, which would mean that resolve never gets called and ends up adding unresolved promises as memory leaks.

This is especially problematic if the rendercomplete gets interrupted by a new render.

[katspaugh]

True, good point. I’ll approve the PR as is then.

[katspaugh]

I personally like the event name, it's clear!

[dukeeagle]

Sick!!!