Mobile GPUs use tile-based rendering. A long thin triangle touches more tiles, so it costs more. That could make you think you need to use Delaunay all the time. But the gain from nicer Delaunay triangles on the GPU is small relative to the time you pay for Delaunay on the CPU. I've measured time profiles on map data. It could be that for games it pays off.
Definitely, you have to understand where your bottlenecks are. That's why it's best just to author good models.
Nanite/triangulation can help relieve GPU bottlenecks but if you're already stomping your CPU it won't help. Whether it's a good fit depends on your workload.
Numbers without benchmarks are useless. :)
During vector map generation we make sure that all data is valid. But our users can import custom GeoJSON layers and they could contain all sorts of self-intersections.
== world.bin
56472 polygons
whole file, best of 7: earstrip 453.4 ms, delaunay32 1696.9 ms
up to 4 14455 polygons: earstrip 0.3 ms, delaunay32 14.4 ms
5-8 8328 polygons: earstrip 0.6 ms, delaunay32 14.5 ms
9-32 18019 polygons: earstrip 6.8 ms, delaunay32 83.7 ms
33-256 13511 polygons: earstrip 66.6 ms, delaunay32 366.9 ms
257 and more 2159 polygons: earstrip 376.8 ms, delaunay32 1209.4 ms
delaunay32: rejected 3039 (by class 0/28/365/1671/975), empty outer ring 0, area off on 0 covered, 1930016 triangles
earstrip: exact 56338, constrained 134
Having triangulation conform to Delaunay is a big advantage though! You should also try out https://github.com/mapbox/earcut.hpp for the benchmark — it got a refine function recently that refines earcut output to Delaunay as well, and earcut+refine is still pretty fast.
thanks, good suggestion! earcut plus refine sounds like sensible comparison.
i’ve since reproduced the world dataset benchmark locally and found that polygon validation was taking about two-thirds of delaunay32’s time on the accepted inputs.
For practical data, a faster approach is usually to triangulate without validation, then just measure if triangulation is valid afterwards (which is simply comparing the sum of triangle areas with polygon area)
Hey! Thanks for Leaflet, earcut and all your other work. I hope some of these ideas turn out useful. Take a look at the branch-free dent count: it's what let us outperform earcut, and it's a big part of why the wasm build is that fast.
The wasm module is 27 KB gzipped, about 41 KB with the base64 wrapper in the npm package.
Hmm. Passkeys are advertised as secure because they are difficult to hack. And since they use the same API as hardware security keys, I can store passkeys on my YubiKey for critical infrastructure.
They’re secure, stored in iCloud, and can be used from any of my Apple devices. And if I need extra security, I can use a hardware key instead. What more could I ask for?
I understand why passkeys are being promoted so heavily. They’re secure by design. Otherwise, companies have to think about all the possible ways their authentication systems could be compromised. And even then, they can still get hacked.
Passwords are weak. People can be tricked into revealing time-based authentication codes. But passkeys? They just work. Your grandma can’t read one out over the phone or write it on a sticky note next to her monitor.
reply