Can I freeze wavesurfer after init?

[kalmnoise]

Hi, I used beta version and it helped me in many ways but there are some things that I don't know if can be done

compared with previous version : 6
this version is much much much faster ( I use it to load large audio between 20 minutes and 2 hours )

so loading is very insanly good,

also responsiveness is better and compared with previous version
previously if for some reason I hide waveform then reshow it it missbehave
but here it is good

but the point where I've a little problem is after loading
I feel like new wavefor take more resources that the previous one, I only use waveform with out real audio ( using data audio )
and using generated peaks on .json file generated by audiowaveform

I disabled interaction, disabled everything but still I found it heavier than previous version

so is there a way to disable anything other than waveform\ view that already rendered and responsiveness?

or is there any other way to improve performance after loading the waveform

because in my use.. I load wavesurfer in very wide container +10000000px according to the audio\video length 200px per second

thank you

[katspaugh]

How are you measuring the resources consumed? Is your UI becoming visibly unresponsive/choppy?
The only heavy part is decoding and rendering. Since you're providing your own peaks, it must be the rendering. With such a wide container, it's not surprising tbh.
I would look into providing your own renderFunction and trying to minimize the amount of canvas operations.

[kalmnoise]

Thank you for answering
actually the UI is not unresponsive I'll tell you how I measuered this:
-first I've only two things in UI which is video above and scrollarea below it
-Linking the movement of scroll area with the video and making it 200px/sec
-it also visualize transcription below the waveform and that is why I'm having large container

I'm moving the scrollarea with the video using [requestAnimationFrame] to make the scrollarea move up to the device maximum fps reaching 144fps smoothly without problem

I was measuring performance.now() difference between eatch frame and the current time in the player.
in version 6 I was able to reach less than 2ms difference without sudden drops while playing
and in version 7 I'm able to reach 15ms difference without sudden drops while playing

in both scenarios I disabled all interactions and because I'm not loading audio I disabled progressing and everything and I did it manualy by increasing width of .progress class ( was more diffecult in the newer version cause it is inside shadow class) but it work just fine and I don't know if calling something inside a shadow-root is related or not

[katspaugh]

So you're moving the playhead and scrolling the waveform in time to the video?

And the action of changing the scrollLeft and resizing the progress element takes 15 ms now?

[kalmnoise]

yes moving scrollLeft of the parent container in which waveform sit in

there is no 15ms - as constant delay
but sometime it cause a delay that is more than 2 ms and not exceeding 15ms

I did a workaround by allowing +- 15ms delay without resyncing the scrollLeft with video

but I was wondering if there is a better way of doing it or a setting that I can do to make it faster

[katspaugh]

Interesting, I always thought that requestAnimationFrame ran at a minimum 16.6-ms rate.
But you're probably measuring the self time of the operations inside the frame, not the time between frames, right?

Anyway, sounds like it's not the rendering of the waveform itself since it's already rendered. It's something in the scrolling/setting the progress. I would start bisecting the problem by commenting out the code that sets the progress width. Then restore it and comment out the code that sets scrollLeft. One of them is probably causing excessive DOM re-flows or re-paints. There are a couple differences in how the DOM tree is structured between v6 and v7 apart from it being a shadow tree.

Also maybe try building a local version of wavesufer with the shadow DOM removed, just use a regular div.

[kalmnoise]

I'm comparing time of the scrollLeft overtime
and time of the video progression
so how different they're overtime

so before ( with version 6 ) the difference was not exceeding 2ms - 3ms
on this version the differece sometime reaching about 15ms as a difference between (Scrolling to time) and Video current Time

which I thought is a good measure in addition to real use measue ( not feeling that the movement is shaky/ or not smooth)

[katspaugh]

One thing that came to my mind is the resize listener that v7 has. Your container doesn’t change its width so I wouldn’t expect this listener to fire, but might be worth checking. You can put a breakpoint there, it’s in renderer.js.

[kalmnoise]

I will try and give you feedback

thank you very much for this good repo and support