-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor: promise-based chunked rendering #3484
Conversation
ESLint Summary View Full Report
Report generated by eslint-plus-action |
Deploying with Cloudflare Pages
|
src/renderer.ts
Outdated
await Promise.allSettled( | ||
Array.from({ length: audioData.numberOfChannels }).map((_, i) => { | ||
const options = { ...this.options, ...this.options.splitChannels?.[i] } | ||
return this.renderChannel([audioData.getChannelData(i)], options, width) | ||
}), | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allSettled
will prevent the catch from being invoked in subsequent renders.
This seems like more render calls would be happing than one might expect.
I think Promise.all
might be the better option here. But I may be miss understanding something here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, thank you, we want to reject the entire promise when one of them fail.
Short description
As outlined in a comment in #3480, I've refactored the code that was awaiting all waveform chunks to be rendered into sequenced promises.
Implementation details
The rendering timeouts are now also promise-based, and it a render timeout is cancelled due to another rendering (e.g. when zooming using a slider), it will also reject the correspondng promise. So it's possible to track the entire chain of promises to determine where
rendercomplete
should be called.@brian-byassee @jason-whitted please review