3 ms·
That's because that demo is using SVG for graphics and hence updating 300+ DOM elements every frame will of course start stuttering... Once I've updated that ex
by toxmeister 8y ago
That's because that demo is using SVG for graphics and hence updating 300+ DOM elements every frame will of course start stuttering... Once I've updated that example to use the hdom-canvas support lib (https://github.com/thi-ng/umbrella/blob/master/packages/hdom-canvas/README.md https://github.com/thi-ng/umbrella/blob/master/packages/hdom...) this will be a non-issue. E.g. here's another demo which draws 10k rectangles @ 60fps. Only once I go >25K, I'm starting to loose framerate (MBP 2016):
https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-10k https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-10k
https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-50k https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-50k
- jefozabuss 8y agoI found a similar issue with the git commit log example (when filtering from initial state and clearing filter) - I guess it can be reproduced via a "heavier" example e.g. a couple hundred nodes with more frequent state changing.
- toxmeister 8y agoThe commit table has a 100ms throttle on key press, but I think might have a bug, need to inquire more... :) There's also a stress test here which updates several hundred nodes each frame: https://github.com/thi-ng/umbrella/tree/master/packages/hdom#benchmark https://github.com/thi-ng/umbrella/tree/master/packages/hdom... E.g. each cell shown requires 3 DOM updates per frame, so in the 256 cells config it updates 768 DOM nodes. On my MBP2016 this config runs at ~35 fps, 192 cells (576 real DOM updates) at 59-60fps