martinfrances107
commented
3 years ago I have just created a PR based on what I said above
When I talk about a new test based on the generation of a world map from a large json file.
Well none of that code exercises code from this module... so I have cut it out from the PR. Its a valid thing to do but I should create a new PR for that in d3-geo.
What I ended doing instead : -
I duplicated the existing sphere test and altered it so that instead of writing to a SVG element it draws to a CANVAS element.
I have altered both benchmark so they output to the screen the mean render time with a standard deviation based on the last 200 frame draws.
from example of my machine I get for a sphere with 505 points. the following render times.
SVG: 11.452 +/- 2.897ms CANVAS: 8.805 +/- 3.70ms
So writing to a canvas element apprears to reduce the render time by 24%.
Any there is little more variability in the mean render time that I like ... but I think this is an improvement.
Fil
I want to revisit our current bench-marking ... I will post a PR in the next few days.. but I want to talk about it publicly first.
By benchmark I mean this file. https://github.com/Fil/d3-geo-voronoi/blob/master/benchmark/sphere.html
I am making progress porting three modules d3-geo, d3-delaunay, d3-geo-voronoi into rust for performance. In my testing I am starting to find sphere.html a little limiting.
From my perspective - a benchmark should be a battery of test simple to understand but exercise a surprisingly large set of "critical path" ... code sections.
I want to add a new benchmark - pulled from the internet - The simplest world map drawing code snippet.
https://www.d3-graph-gallery.com/graph/backgroundmap_canvas_basic.html
This adds to the bench-marking as it is CANVAS based. not SVG based.
It covers sections of code in this module that will be found in any performance heavy user code. Namely writing directly to the canvas's 2d graphics context
Lastly I want to fix the current benchmark - so looking back at sphere.html.
a) The number of patches is fix... I want to add a range slider so the evaluator can increase or decrease the number of points rendered - As the performance characteristics of mobile and laptop and desktops are different.
b) There is a performance kink in the existing code ..in the browser's "dev tools" performance monitoring tab.. if you look at the performance graphs about every 4 seconds the is a glitch and for a short time it starts to drop frames. I can make to go away with a two line refactor .. if I use requestAnimationFrame instead of redrawing on a timer.
c) It only cover a small patch of the sphere.. it looks better if it cover the whole globe.