-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Improve rendering performance when pxPerSec is high #909
Conversation
* Adds an optional 'partialRender' parameter to enable * Calculates and renders peaks only for current visible waveform * Keeps track of currently calculated/rendered peaks to avoid duplicate calculation and only incremental scroll changes are rendered Tested all combinations of Canvas/MultiCanvas and Wave/Bars rendering at various zoom levels.
Thanks a lot! Sorry it took so long to merge! |
Awesome work! Thanks for adding this. Is this gonna make its way into the npm version? Working in nodejs and have to work using PC and Mac so need to be able to update via npm. |
I'm waiting for feedback in the last open PR and will release afterwards. |
ok, thanks. |
Question on this. Should this resolve an issue I have where the waveform disappears when the pxsPerSec value is above 260? Using zoom(270) |
(wrote this before your edit) I think the waveform disappearing with zooming is a limitation of single canvas. Probably the internal representation of your canvas is > 4000px or whatever the size limitation of canvas is on your particular browser's/gpu's implementation. This PR will not fix that, because the canvas allocation will still fail. You should try multi-canvas to address this, but now this PR will mean that you won't over-render to the whole multi-canvas when the option is set. I've used zoom levels well above 270 in my test app, I think into the thousands. IMO multi-canvas should be the default and you should consider removing single-canvas because it's strictly a subset of the functionality of multi-canvas. |
I've made MultiCanvas the default renderer and published version 1.3.0 on npm. Thanks everyone! |
* Adds an optional 'partialRender' parameter to enable * Calculates and renders peaks only for current visible waveform * Keeps track of currently calculated/rendered peaks to avoid duplicate calculation and only incremental scroll changes are rendered Tested all combinations of Canvas/MultiCanvas and Wave/Bars rendering at various zoom levels.
…is high (#909) (#924) * Improve rendering performance when pxPerSec is high (#909) * Adds an optional 'partialRender' parameter to enable * Calculates and renders peaks only for current visible waveform * Keeps track of currently calculated/rendered peaks to avoid duplicate calculation and only incremental scroll changes are rendered * Tested all combinations of Canvas/MultiCanvas and Wave/Bars rendering at various zoom levels. * travis with prune for more accurate dependency resolution * updated karma-webpack to work with webpack 2
refs katspaugh#1127 Before katspaugh#909, calling `drawBuffer` to redraw the wave invoked `drawer.drawPeaks` which in turn invoked `drawer.setWidth` which always caused the canvas to be cleared as a side effect of `drawer.updateSize`. In katspaugh#909 `setWidth` was changed to short circuit if the width did not change. This now causes the waveform to be redrawn on top of the previous rendition, making the edges of the wave appear less crisp. This change makes `setWidth`/`setHeight` return a boolean to indicate whether changes were needed. If not, `drawer.clearWave` is called manually. So we make sure that the previous wave is always cleared, but do not perform the possibly performance intensive task of clearing the canvas twice if it already happened as a side effect of `setWidth`.
refs #1127 Before #909, calling `drawBuffer` to redraw the wave invoked `drawer.drawPeaks` which in turn invoked `drawer.setWidth` which always caused the canvas to be cleared as a side effect of `drawer.updateSize`. In #909 `setWidth` was changed to short circuit if the width did not change. This now causes the waveform to be redrawn on top of the previous rendition, making the edges of the wave appear less crisp. This change makes `setWidth`/`setHeight` return a boolean to indicate whether changes were needed. If not, `drawer.clearWave` is called manually. So we make sure that the previous wave is always cleared, but do not perform the possibly performance intensive task of clearing the canvas twice if it already happened as a side effect of `setWidth`.
refs katspaugh#1127 Before katspaugh#909, calling `drawBuffer` to redraw the wave invoked `drawer.drawPeaks` which in turn invoked `drawer.setWidth` which always caused the canvas to be cleared as a side effect of `drawer.updateSize`. In katspaugh#909 `setWidth` was changed to short circuit if the width did not change. This now causes the waveform to be redrawn on top of the previous rendition, making the edges of the wave appear less crisp. This change makes `setWidth`/`setHeight` return a boolean to indicate whether changes were needed. If not, `drawer.clearWave` is called manually. So we make sure that the previous wave is always cleared, but do not perform the possibly performance intensive task of clearing the canvas twice if it already happened as a side effect of `setWidth`.
refs #1127 Before #909, calling `drawBuffer` to redraw the wave invoked `drawer.drawPeaks` which in turn invoked `drawer.setWidth` which always caused the canvas to be cleared as a side effect of `drawer.updateSize`. In #909 `setWidth` was changed to short circuit if the width did not change. This now causes the waveform to be redrawn on top of the previous rendition, making the edges of the wave appear less crisp. This change makes `setWidth`/`setHeight` return a boolean to indicate whether changes were needed. If not, `drawer.clearWave` is called manually. So we make sure that the previous wave is always cleared, but do not perform the possibly performance intensive task of clearing the canvas twice if it already happened as a side effect of `setWidth`.
duplicate calculation and only incremental scroll changes are rendered
Tested all combinations of Canvas/MultiCanvas and Wave/Bars rendering
at various zoom levels.