|
|
|
|
|
by nasso_dev
827 days ago
|
|
very interesting... i am literally in the middle of building my own canvas rendering engine so this article really made me excited it saddens me a bit that the author doesn't talk about the performance of their implementation... one of the great benefits of using canvas to render ui is that you are able to render far more elements than using the dom with a much smaller memory footprint im curious to know more about their rendering strategy... does it just redraw everything at 60hz or do they have a smarter way to trigger redraws? do they always redraw the entire canvas or do they somehow only redraw updated regions? |
|
Internally we are using this for our Aha! Whiteboards product, which is built on top of Fabric.js The Fabric framework provides a lot of the rendering optimizations out of the box: it will only render shapes that are visible in the current viewport. Fabric resets and re-renders the entire canvas every time, but it will only re-render as needed. There are also instances where we need to manually trigger a re-render based on state changes to the whiteboard.
So the rendering performance thus far has not been an issue. We are always looking for improvements to our product and the implementation of CanvaSX, but we didn't want to prematurely optimize or over-engineer the framework.